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Executive  summary 

In  response  to  the  growing  pressure  to  limit  defense  spending,  acqui¬ 
sition  professionals  in  the  Department  of  Defense  (DOD)  are  work¬ 
ing  to  ensure  that  the  government  has  access  to  the  data  needed  to 
support  competition,  maintenance,  and  sustainment  over  the  full  life 
cycle  of  weapon  systems.  In  DOD  data  acquisitions,  the  right  of  the 
federal  government  to  reuse,  modify,  reproduce,  perform,  display,  re¬ 
lease,  and  disclose  data — particularly  computer  software — lias  be¬ 
come  an  important  topic  in  contract  negotiations. 

As  part  of  the  on-going  DOD  effort  to  update  guidance  on  software 
acquisitions,  CNA  was  asked  to  provide  a  synthesis  of  the  literature  on 
software  valuation  and  to  identify  best  practices  for  evaluating  the 
prices  quoted  by  suppliers  for  software  licenses,  including  licenses  for 
additional  data  rights.  Negotiated  on  a  contract-by-contract  basis, 
such  licenses  provide  the  government  with  data  rights  to  software 
above  and  beyond  those  that  are  generally  conveyed  with  software  de¬ 
liverables  (e.g.,  government  purpose  rights  may  be  conveyed  instead 
of  only  restricted  rights  to  software) . 

This  paper  recognizes  that  the  type  of  data  that  may  be  licensed  by 
the  government  includes  everything  from  technical  data  to  software 
and  special  works.  In  most  cases,  the  scope  of  rights  that  are  generally 
conveyed  with  software  deliverables  depends  on  the  nature  of  the 
funding  used  to  create  the  software.  Regardless,  the  contractor  that 
created  the  data  is  always  the  owner  and  the  copyright  holder.  Unless 
there  are  other  restrictions,  the  contractor  is  also  able  to  use  the  in¬ 
formation  for  any  other  purpose. 

Given  the  complexity  of  discussing  the  full  breadth  of  data  rights,  we 
focus  in  this  paper  primarily  on  computer  software  developed  exclu¬ 
sively  with  private  funds  or  with  independent  research  and  develop- 


See  DEARS  227.71  and  227.72  for  policy  statements  on  this  issue.  Exam¬ 
ples  of  restrictions  on  use  could  in  export  controls  or  the  terms  speci¬ 
fied  in  DOD  Directive  5430.24. 
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ment  (IR&D)  funds.  We  assume  that  DOD  is  considering  acquiring  a 
license  for  government  purpose  rights  (GPR)  (i.e.,  the  right  to  use, 
modify,  reproduce,  release,  perform,  display,  or  disclose  within  the 
government),  instead  of  either  restricted  rights  (RR)  or  the  rights 
that  are  conveyed  by  licenses  customarily  provided  to  the  public.  The 
government’s  purpose  in  acquiring  such  expanded  rights  would  be  to 
address  its  life-cycle  needs  for  the  maintenance,  sustainment,  and 
competition  as  effectively  and  efficiently  as  possible. 

In  this  paper,  we  describe  the  valuation  methods  used  by  DOD  and 
industry  to  estimate  software  costs  and  to  assign  value  to  such  ex¬ 
panded  licenses.  In  general,  industry  focuses  on  initial  development 
cost  and  on  the  importance  for  future  profits  of  control  over  data 
rights.  In  contrast,  DOD  is  concerned  with  life-cycle  acquisition  costs. 

To  determine  DOD  willingness-to-pay  for  expanded  licenses,  we 
characterize  the  solicitation  process  for  software  as  a  two-stage  bar¬ 
gaining  problem.  Analyzing  this  stylized  version  of  the  acquisition 
process  makes  it  possible  to  identify  the  factors  that  determine  the 
value  to  the  government  of  these  licenses. 

We  find  that  the  benefit  of  expanded  licenses  to  DOD  arises  from 
their  impact  on  future  competition  and  costs.  Two  things  must  occur 
for  expanded  licenses  to  be  worth  the  additional  cost  to  DOD.  First, 
the  additional  information  covered  by  the  license  must  be  transferra- 
ble  to  alternative  suppliers,  either  competing  commercial  companies 
or  organic  DOD  facilities.  Second,  the  information  covered  by  the  li¬ 
cense  must  be  useful  to  alternative  suppliers,  to  the  extent  that  it  ac¬ 
tually  lowers  their  production  costs.  Unless  both  of  these  conditions 
are  met,  paying  a  higher  licensing  fee  for  an  expanded  license  will 
raise,  rather  than  lower,  DOD  acquisition  costs. 

We  see  that  expanded  licenses  are  valuable  to  DOD  only  to  the  extent 
that  they  allow  alternative  suppliers  to  bid  more  aggressively  in  the  fu¬ 
ture.  Furthermore,  the  extent  of  supplier  cost  savings  attributable  to 
expanded  licenses  defines  the  maximum  that  the  government  is  will¬ 
ing  to  pay  for  the  license  itself.  Paying  more  than  this  amount  for  a  li¬ 
cense  would  raise,  not  lower,  life-cycle  acquisition  costs. 


This  approach  provides  a  variety  of  practical  insights  for  acquisitions 
professionals.  It  indicates 

•  what  factors  influence  DOD’s  willingness  to  pay  more  for  ex¬ 
panded  licenses; 

•  how  software  cost  models  can  be  used  to  evaluate  prices  quot¬ 
ed  for  expanded  licenses;  and 

•  when  companies  are  likely  to  refuse  to  quote  a  license  fee  for 
expanded  licenses,  or  to  quote  a  fee  that  exceeds  the  govern¬ 
ment’s  willingness-to-pay,  or  to  abstain  altogether  from  partic¬ 
ipating  in  the  solicitation  process. 

We  provide  a  variety  of  references  that  allow  the  reader  to  explore 
specific  issues  in  greater  depth. 
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1  Introduction 
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In  recent  years,  the  debate  over  the  ownership  and  control  of  data' 
and  data  rights  has  intensified  as  it  has  become  increasingly  essential 
to  modern  weapon  systems.  Evidence  of  efforts  to  clarify  the  gov¬ 
ernment’s  position  on  the  acquisition  of  licenses  for  additional  data 
rights  can  be  found  in  recent  legislation,  in  Department  of  Defense 


We  use  the  term  “data”  generically  to  refer  to  any  or  all  of  the  following: 
technical  data,  computer  software,  and  special  works.  The  formal  defini¬ 
tions  for  these  terms  are  discussed  in  appendix  A  of  this  paper. 

Nelson,  Clark,  and  Spurlock  observe  that,  “software  plays  an  ever- 
increasing  role  in  the  operation  of  DOD  weapon  systems;  Command, 
Control,  Communications,  Computers  &  Intelligence  (C4I)  systems;  and 
management  information  systems”  [1],  See  also  [2]. 

Section  822  of  the  Duncan  Hunter  National  Defense  Authorization  Act 
for  FY  2009  [5]  required  the  Secretary  of  Defense  to  issue  guidance  to 


(1)  establish  criteria  for  defining  the  legitimate  interests  of  the  Unit¬ 
ed  States  and  the  party  concerned  in  technical  data  pertaining  to 
an  item  or  process  to  be  developed  under  the  agreement; 

(2)  require  that  specific  rights  in  technical  data  be  established  dur¬ 
ing  agreement  negotiations  and  be  based  on  negotiations  be¬ 
tween  the  United  States  and  the  potential  party  to  the 
agreement...;  and 

(3)  require  the  program  manager  for  a  major  weapon  system  (or  an 
item  of  personnel  protective  equipment  that  is  to  be  developed 
using  a  non-FAR  agreement)  to  assess  the  long-term  technical  da¬ 
ta  needs  of  such  a  system  or  item. 


The  Weapon  Systems  Acquisition  Reform  Act  of  2009  [6]  identified 
three  measures  involving  data  rights  that  were  designed  to  encourage 
competition:  (1)  “use  of  modular,  open  architectures  to  enable  competi¬ 
tion  for  upgrades,”  (2)  “acquisition  of  complete  technical  data  packag¬ 
es,”  and  (3)  “licensing  of  additional  suppliers.” 
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(DOD)  policy  statements,  and  in  on-going  initiatives  to  revise  the 
Defense  Federal  Acquisition  Regulations  Supplement  (DEARS).  This 
evidence  indicates  a  growing  awareness  that  decisions  concerning  li¬ 
cense  scope  made  during  the  initial  stages  of  the  acquisition  process 
can  have  far-reaching  implications  over  a  program’s  life  cycle  [15] . 

In  response  to  these  policy  initiatives,  DOD  acquisition  professionals 
are  reviewing  sourcing  and  delivery  practices  as  they  confront  the 
challenge  of  limiting  sustainment  costs.  They  view  the  strategic  man¬ 
agement  of  license  scope  as  a  fundamental  opportunity  for  defense 


Section  824  of  the  Ike  Skelton  National  Defense  Authorization  Act  for  FY 
2011  [7]  required  the  Secretary  of  Defense  to  review  existing  guidance 
concerning  the  acquisition  of  data  rights  “to  ensure  that  the  United 
States — 


(1)  preserves  the  option  of  competition  for  contracts  for  the  produc¬ 
tion  and  sustainment  of  systems  or  subsystems  that  are  developed 
exclusively  with  federal  funds  as  defined  in  accordance  with  the 
amendments  made  by  this  section;  and 

(2)  is  not  required  to  pay  more  than  once  for  the  same  technical  da¬ 
ta.” 

This  legislation  also  changes  the  status  of  technical  data  developed  using 
IR&D  funds  received  by  a  DOD  contractor  as  an  overhead  charge  on  an 
existing  contract.  Such  technical  data  are  now  to  be  treated  as  though 
they  were  developed  using  federal  funds  rather  than  private  funds.  This 
legislation  was  amended  for  consistency  by  Section  815  of  the  National 
Defense  Authorization  Act  for  FY  2012  [8] . 

Recent  memoranda  from  the  Under  Secretary  of  Defense  ([9],  [10], 
[11])  require  DOD  to  adopt  open  systems  architectures  and  to  set  rules 
for  acquisition  of  technical  data  rights. 

Several  DFARS  cases  in  process  at  the  beginning  of  2012  directly  ad¬ 
dressed  data  rights  issues.  DFARS  Case  2009-D031  [12]  was  a  proposed 
rewrite  of  the  rules  authorizing  access  for  certain  types  of  government 
support  contractors  to  technical  data  belonging  to  prime  contractors 
and  other  third  parties.  DFARS  Case  2010-D001  [13]  was  a  proposed  re¬ 
write  of  all  DFARS  sections  that  pertain  to  technical  data.  (A  version  of 
this  case  has  been  in  process  since  2003;  it  was  placed  on  hold  in  May  of 
2012.)  DFARS  Case  2012-D022  [14]  was  designed  to  provide  guidance 
relating  to  rights  in  technical  data  under  contracts  for  the  production 
and  sustainment  of  systems  or  subsystems. 
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and  commercial  entities  to  collaborate  by  increasing  operational  effi¬ 
ciencies,  reducing  development  and  sustainment  costs,  and  creating 
market  structures  that  encourage  competition. 

Nevertheless,  licenses  for  additional  data  rights  are  potentially  very 
expensive.  Thus,  determining  the  long-term  implications  of  having 
access  to  this  information  is  essential — particularly  within  complex 
contract  structures  where  multiple  layers  of  data  rights  are  likely  in¬ 
volved.  To  gain  insight  into  this  problem,  policy-makers  are  seeking 
to  address  the  following,  basic  questions: 

•  When  should  DOD  require  delivery  of  data? 

•  When  should  DOD  obtain  licenses  for  additional  data  rights? 

•  How  much  should  DOD  pay? 

Data  rights  negotiations:  context  and  outcomes 

Why  data  and  data  rights  are  different  from  other  goods  and  ser¬ 
vices 


Data — defined  as  computer  software  and  technical  data  for  the  pur¬ 
poses  of  this  report — have  been  described  as  “intellectual  property” 
[16],  “intangible  assets”  [17],  “public  goods”  [18],  “knowledge”  [19], 
and  “proprietary  information”  [20].  These  labels  are  used  in  various 
contexts  to  describe  items  that  are  expensive  or  difficult  to  create  ini¬ 
tially  but  that  are  free  (or  nearly  so)  to  reproduce  and  distribute. 
Conventional  goods,  in  contrast,  are  costly  both  to  create  and  to  re¬ 
produce  and  distribute. 

Such  labels  clearly  apply  to  the  data  that  pertain  to  DOD  acquisitions. 
For  example,  a  ship  hull  design,  the  software  code  used  in  sensors, 
and  the  wiring  diagram  for  an  avionics  circuit  board  are  all  costly  to 
develop  but,  once  developed,  are  virtually  costless  to  reproduce  and 
distribute. 

The  term  “data  rights”  refers  to  the  government’s  license  rights  in  da¬ 
ta.  In  other  words,  the  government’s  data  rights  determine  the  extent 
of  its  ability  to  use,  reproduce,  modify,  perform,  display,  release,  and 
disclose  data  within  the  government  and,  under  some  circumstances, 
to  disclose  data  outside  the  government  to  third  parties. 
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Why  data  rights  have  value 

In  today’s  volatile  technology  market,  companies  that  establish  claims 
to  intellectual  property  are  often  able  to  secure  highly  profitable  con¬ 
tract  terms.  In  such  cases,  proprietary  technologies  serve  as  barriers 
that  make  it  more  difficult  for  new  companies  to  enter  the  market  in 
question.  For  DOD,  such  barriers  limit  acquisition  choices  and  in¬ 
crease  the  risk  of  vendor  lock  and  monopoly  pricing  [40] .  Thus,  cur¬ 
rent  DOD  policy  emphasizes  reducing  entry  barriers  and  encourages 
competition. 

However,  eliminating  future  barriers  to  entry  may  involve  significant 
up-front  cost.  Under  federal  law,  a  firm  that  develops  intellectual 
property  (i.e.,  data)  retains  the  title  to  it.  Even  if  the  intellectual 
property  is  developed  with  government  funding,  the  government  ac¬ 
quires  a  license  for  the  data — not  ownership.  In  general,  the  scope  of 
this  license  will  depend  on  the  nature  of  the  data,  the  source  of  fund¬ 
ing,  and  the  terms  that  were  agreed  upon  during  negotiations  be¬ 
tween  the  government  and  the  supplier. 

For  industry,  data — whether  developed  for  the  government  or  the 
commercial  market — represent  a  potential  source  of  future  profits.8 
If  a  company  owns  intellectual  property  that  is  of  interest  to  DOD — 
but  is  not  already  available  either  under  license  to  the  government  or 
as  a  deliverable  on  a  previous  contract — it  is  likely  that  the  company 
will  agree  to  license  the  information  only  if  it  is  compensated  for  the 
negative  impact  of  the  license  on  expected  future  profits. 

As  mentioned  above,  the  value  assigned  to  data  (and  to  data  rights)  is 
defined  through  negotiations  between  DOD  and  its  suppliers.  Cer¬ 
tain  types  of  data  rights  are  automatically  conveyed  to  the  govern¬ 
ment  with  unlimited  rights.  These  include  computer  software 


“Vendor  lock”  refers  to  a  situation  in  which  an  organization  becomes 
dependent  on  a  single  manufacturer  or  supplier  for  products  or  ser¬ 
vices.  In  other  words,  the  organization  cannot  transfer  work  to  another 
supplier  without  unacceptable  costs  or  inconvenience.  This  dependence 
is  typically  the  result  of  specifications  or  other  technical  data  controlled 
by  the  incumbent  (i.e.,  the  current  manufacture  or  supplier). 

In  appendix  B,  we  discuss  the  sources  of  market  for  non-commercial 
software  developed  for  the  government. 
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documentation  delivered  under  contract;  form,  fit,  and  function  da¬ 
ta;  and  data  that  are  necessary  for  installation,  operation,  mainte¬ 
nance,  or  training  purposes  (other  than  detailed  manufacturing  or 
process  data).  For  data  rights  that  are  not  automatically  conveyed, 
the  starting  point  for  such  negotiations  is  determined  by  a  combina¬ 
tion  of  federal  law,  DOD  regulations,  and  policy.  Appendix  A  pro¬ 
vides  an  overview  of  the  default  DEARS  licenses  for  commercial  and 
noncommercial  software  and  technical  data.10 

As  a  general  rule,  default  DEARS  licenses  for  data  depend  on  who 
paid  for  the  initial  cost  of  creating  the  work.  The  scope  of  default  li¬ 
censes  increases  as  the  government’s  share  of  the  development  cost 
increases.  Nevertheless,  it  is  important  to  remember  that  the  default 
license  merely  defines  the  initial  bargaining  positions  of  the  parties 
involved  in  DOD  acquisitions.  In  the  end,  access  to  data  is  governed 
by  the  specific  terms  of  the  agreement  that  is  negotiated  by  DOD  and 
its  suppliers. 

Data  rights  debates 

When  suppliers  have  exclusive  rights  to  data,  DOD  may  be  forced  to 
award  a  series  of  sole  source  contracts.  Some  recent  cases  illustrate 
how  limited  access  to  data  has  prevented  competing  suppliers  from 
responding  to  DOD  solicitations. 

•  M4/M4A1  carbine:  In  the  mid-1990s,  the  Army  failed  to  safe¬ 
guard  a  technical  data  package  licensed  from  Colt  Defense, 
LLC  (Colt).  As  a  result,  the  Army  agreed  in  1998  to  amend  the 
existing  license  and  include  a  “sole  source”  provision  naming 


See  DEARS  252.227-7013(b)  (1)  and  252.227-7014(b)  (1)  for  a  complete 
description  of  this  category  of  data  rights. 

We  note  in  passing  that  although  there  are  DEARS  policy  statements 
concerning  the  acquisition  of  licenses  for  commercial  software,  there  is 
no  default  contract  language.  The  presumption  is  that  the  government 
will  acquire  the  license  customarily  granted  to  the  general  pub¬ 
lic — unless  other  arrangements  are  made  or  unless  the  terms  of  the  cus¬ 
tomary  license  are  not  consistent  with  federal  law.  See  DFARS  227.7202 
for  specific  details. 
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Colt  as  the  only  avithorized  supplier  of  this  weapon  for  a  10- 
year  period.11 

•  Apache  helicopter,  main  rotor  strap  assembly:  In  the  late  1990s, 
McDonnell  Douglas  Helicopter  Company  (MDHC)  inde¬ 
pendently  developed  an  improved  version  of  a  rotor  strap  as¬ 
sembly  that  had  been  previously  manufactured  by  KSD,  Inc. 
Since  the  Army  did  not  pay  MDHC  for  these  refinements,  the 
court  found  that  the  Army  had  no  claim  to  the  technical  data 
that  defined  the  strap  assembly.  Without  access  to  this  infor¬ 
mation,  KSD  was  not  able  to  establish  itself  as  an  “approved 
source”  and  thus  was  unable  to  bid.  ~ 

•  SPITFIRE  radio  terminals:  To  develop  an  organic  repair  capa¬ 
bility  for  this  equipment,  the  Army  requested  a  technical  data 
package  from  the  manufacturer.  The  manufacturer  subse¬ 
quently  quoted  a  price  of  $100  million  for  the  data  alone,  an 
amount  roughly  equal  to  80  percent  of  total  program  costs  over 
a  five-year  period.  As  a  result,  the  Army  continued  to  purchase 
maintenance  services  from  the  manufacturer  ([22],  p.  17). 

•  C-17  aircraft  and  F-22  aircraft:  The  Air  Force  did  not  initially  li¬ 
cense  the  technical  data  needed  to  develop  an  organic  mainte¬ 
nance  capability  at  government  repair  depots.  Some  “sub¬ 
vendors”  (subcontractors  to  the  primary  supplier)  were  later 
unwilling  to  provide  the  data  rights  that  would  allow  the  Air 
Force  to  establish  this  depot  capability  ([23],  pp.  6-7). 

•  C-130J  aircraft:  The  Air  Force  did  not  initially  license  the  tech¬ 
nical  data  needed  to  purchase  C-130J  spare  parts  through 
competitive  procurements.  When  the  prime  contractor  de¬ 
clined  to  provide  a  technical  data  rights  package  for  these 


After  the  sole  source  clause  in  the  “M4  Addendum”  expired  in  2009,  the 
Army  issued  an  open  solicitation  and  awarded  a  contract  to  a  different 
supplier.  The  unit  cost  in  the  new  contract  was  roughly  half  the  price 
charged  by  Colt  in  its  final  delivery  order.  Appendix  D  presents  the  his¬ 
tory  of  this  dispute. 

Appendix  E  presents  the  facts  of  KSD,  Inc.  versus  the  United  States  and 
McDonnell  Douglas  Helicopter  Company  [21]  as  provided  in  the  court’s 
opinion.  KSD  protest  of  the  sole  source  bid  rationale  was  unsuccessful. 


parts,  the  Air  Force  had  to  negotiate  multiple  partnership 
agreements  with  the  sub-vendors  who  owned  the  proprietary 
data  used  in  the  production  process  ( [23],  pp.  7-8) . 

•  Up-armored  High-Mobility  Multipurpose  Wheeled  Vehicles: 

The  Army  did  not  initially  license  the  technical  data  needed  to 
support  a  dual-sourcing  response  to  a  wartime  surge  in  de¬ 
mand  for  this  vehicle.  The  original  manufacturer  later  refused 
to  sell  the  technical  data  to  DOD  when  demand  grew  from 
1,407  vehicles  in  August  2003  to  8,105  vehicles  in  September 
2004.  As  a  result,  the  Army  was  unable  to  use  alternative  sup¬ 
pliers  ([23],  p.  8). 

•  Airborne  Warning  and  Control  System  (AWACS)  spares:  The 

Defense  Contract  Management  Agency  recommended  that  the 
Air  Force  acquire  AWACS  cowlings  (metal  engine  coverings) 
on  a  competitive  basis  because  “the  original  equipment  manu¬ 
facturer’s  proposed  price  was  not  fair  and  reasonable  and  be¬ 
cause  another  potential  source  for  the  part  was  available”  [24] . 
However,  the  Air  Force  had  not  licensed  the  technical  data 
needed  to  support  such  an  acquisition  strategy  and  thus  was 
forced  to  award  a  sole  source  contract  to  the  original  manufac¬ 
turer  in  2003  ([24],  pp.  10-11). 


The  next  step 

This  paper  provides  advice  on  data  rights  questions  in  the  context  of 
software  acquisitions.  In  the  next  chapter,  we  discuss  the  link  between 
the  choice  of  a  software  cost  estimation  methodology  and  the  respec¬ 
tive  roles  of  DOD  and  industry  as  customer  and  supplier.  We  provide 
a  brief  introduction  to  many  of  the  most  popular  estimation  tools  and 
indicate  how  they  could  be  used  by  both  DOD  and  industry  analysts. 

In  chapter  3,  we  analyze  software  contracting  as  a  bargaining  prob¬ 
lem  in  which  DOD  must  choose  whether  to  incur  the  cost  of  addi¬ 
tional  data  rights — i.e.,  a  “package”  of  rights  above  and  beyond  those 
which  are  automatically  granted  by  the  relevant  DEARS  clauses.  We 
use  a  numerical  example  to  illustrate  the  value  to  DOD  of  expanded 
license  rights  for  software,  and  we  provide  a  more  general  example  in 
appendix  C.  We  show  how  DOD’s  willingness  to  pay  for  such  licenses 
is  linked  to  their  impact  on  future  competition — and  on  the  ex¬ 
pected  usefulness  of  the  information  to  future  suppliers  (not  on  the 
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costs  incvirred  by  the  original  developer) .  This  finding  can  be  used  by 
acquisitions  officials  to  build  a  framework  for  evaluating  bids  that  in¬ 
clude  prices  for  expanded  licenses. 


2  Valuation  strategies  for  data  rights 

Over  the  past  20  years,  software  has  become  an  important  cost  driver 
in  DOD  acquisitions,  both  large  and  small.  Initial  software  develop¬ 
ment  is  labor  intensive.  However,  many  of  the  tasks  associated  with 
development  occur  only  once.  Once  software  code  has  been  written 
and  tested,  the  initial  developer  need  only  replicate  and  distribute 
the  code,  which  is  usually  an  inexpensive  process.  Thus,  permission 
to  use,  modify,  reproduce,  release,  perform,  display  or  disclose  soft¬ 
ware  code  provides  DOD  (as  customer)  with  an  opportunity  for  sub¬ 
stantial  savings — as  long  as  the  supplier  agrees. 

In  this  section,  we  compare  the  methods  that  suppliers  use  to  deter¬ 
mine  their  “willingness  to  license”  software  with  the  tools  that  DOD 
uses  to  estimate  its  “willingness  to  pay.”  It  is  important  to  remember 
that  even  “noncommercial”  software  will  generally  have  some  market 
value.  (We  review  the  reasons  for  this  claim  in  appendix  B.) 

The  basic  difference  between  the  approaches  used  by  DOD  and  in¬ 
dustry  is  relatively  straightforward:  DOD  expects  to  use  software  de¬ 
velopment  cost  models  to  assign  a  value  to  both  software  and 
expanded  data  rights  (if  any),  while  suppliers  use  market-based  valua¬ 
tion  techniques  that  are  independent  of  initial  development  costs. 

There  are  also  differences  in  preferred  negotiation  processes.  Some 
suppliers  argue  that  the  prices  quoted  for  licenses  for  additional 
rights  should  not  be  finalized  until  near  contract  completion:  at  that 
point,  the  full  value  of  the  additional  rights  would  be  known.  They  al¬ 
so  argue  that  negotiating  these  rights  at  the  end  of  the  contract  could 
reduce  risk  for  both  DOD  and  the  supplier  and  provide  a  fairer  pric¬ 
ing  calculation. 


Since  the  majority  of  software  costs  are  based  on  human  effort,  many 
cost  estimate  methods  provide  costs  in  terms  of  human-months. 

Potter  [53]  argues  that  “the  closer  one  comes  to  a  final  product,  the 
more  realistic  will  be  the  estimate  of  future  cash  flow.  Waiting  until  near 
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In  contrast,  DOD  acquisitions  officials  argue  that  they  cannot  defer 
data  rights  negotiations  until  the  end  of  a  contract:  if  they  did,  they 
would  risk  being  held  hostage  by  a  supplier  seeking  excessive  com¬ 
pensation.  Despite  these  differences,  all  parties  must  agree  on  both 
the  contracting  process  and  the  financial  terms  negotiated — or  no 
contract  will  be  awarded. 

DOD  approaches  to  data  rights  valuation 

Currently,  DOD  has  no  standard  method  for  determining  the  value 
of  licenses  for  additional  data  rights.  Each  program  office  determines 
the  details  of  its  own  approach;  these  approaches  are  typically  based 
on  some  component  of  the  overall  software  cost  estimation  exercise. 

Below,  we  describe  the  types  of  tools  that  are  used  to  estimate  the 
overall  development  cost  of  software.  In  the  next  chapter,  we  discuss 
how  these  tools  can  be  used  to  evaluate  prices  quoted  for  additional 
data  rights-as  distinct  from  the  cost  of  the  software  itself. 

Software  size  and  software  cost 

Since  writing  software  code  is  a  labor  intensive  activity,  most  cost  es¬ 
timation  models  are  based  on  a  measure  of  software  size.1’  There  are 
several  common  measures;  the  simplest  is  source  lines  of  code 
(SLOC).  ’  Unfortunately,  this  intuitively  appealing  measure  is  diffi- 


the  end  of  product  development  to  negotiate  royalties  can,  however,  give 
rise  to  serious  problems  in  reaching  a  negotiated  settlement.” 

Chapter  13  of  the  Air  Force  Guidelines  for  Successful  Acquisition  and 
Management  of  Software  Intensive  Systems  [25]  provides  a  general 
overview  of  the  issue.  The  Software  Development  Cost  Estimating 
Guidebook  [26],  developed  by  Price  Systems  LLC  with  the  support  of 
the  Naval  Center  for  Cost  Analysis  (NCCA)  and  the  Defense  Acquisition 
University  (DAU),  provides  a  detailed  description  of  the  mechanics  of 
software  cost  estimating. 

David  Wheeler — the  author  of  SLOCCount,  a  popular  open  source  tool 
used  to  estimate  software  development  cost — defines  SLOC  as  follows: 
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A  physical  source  line  of  code  (SLOC)  is  a  line  ending  in  a 
newline  or  end-of-file  marker,  and  which  contains  at  least  one 
non-whitespace  non-comment  character.  Comment  delimiters 


cult  to  specify  in  the  early  stages  of  projects  in  general,  for  projects 
subject  to  “requirements  creep,”  for  projects  dependent  upon  emerg¬ 
ing  technologies,  etc.  Two  alternative  measures  of  size  are  function 
points  [29],  [30],  [31]  and  feature  points  [32].  The  function  point 
approach  was  developed  to  analyze  management  information  systems 
(MIS);  the  feature  point  measure  was  developed  for  real-time  or  em¬ 
bedded  systems.  Predictive  object  points  (POPs)  [33],  a  newer  meas¬ 
ure,  was  designed  to  capture  the  distinctive  architecture  of  object- 
oriented  software.  (Appendix  F  provides  further  details  for  these 
measures.) 

The  following  models  rely  on  SLOC,  POPs,  and  other  size  measures 
to  estimate  software  costs;  they  have  been  used  singly  or  together  by 
DOD  to  evaluate  bids. 

•  COCOMO  (Constructive  COst  MOdel)  was  developed  by 
Barry  Boehm  at  TRW  Aerospace  and  was  first  published  in 
1981  [34].  The  original  model  was  estimated  using  SLOC  ob¬ 
servations  from  63  TRW  projects.  The  current  version,  known 
as  COCOMO ™  II,  allows  the  user  to  choose  either  SLOC  or 
function  points  to  develop  software  cost  estimates. 
COCOMO1"  II  consists  of  a  series  of  submodels  that  are  used 
at  different  stages  in  the  software  development  process.17 


(characters  other  than  newlines  starting  and  ending  a  com¬ 
ment)  are  considered  comment  characters.  Data  lines  only  in¬ 
cluding  whitespace  (e.g.,  lines  with  only  tabs  and  spaces  in 
multiline  strings)  are  not  included.  [27] 

Leung  and  Zhang  [28]  review  a  number  of  alternative  SLOC  definitions. 

The  COCOMO1'1  II  Model  Definition  Manual  [35]  describes  two  of  these 
submodels  as  follows: 


•  The  Post-Architecture  model  is  a  detailed  model  that  is  used  once 
the  project  is  ready  to  develop  and  sustain  a  fielded  system.  The  sys¬ 
tem  should  have  a  life-cycle  architecture  package,  which  provides 
detailed  information  on  cost  driver  inputs  and  enables  more  accu¬ 
rate  cost  estimates. 

•  The  Early  Design  model  is  a  high-level  model  that  is  used  to  explore 
the  architectural  alternatives  or  incremental  development  strategies. 
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•  Software  Lifecycle  Management  (SLIM)  is  a  proprietary  suite 
of  cost  estimating  tools,  which  was  created  by  Lawrence  Put¬ 
nam  Sr.  in  1978;  it  is  currently  distributed  by  QSM,  Inc.  SLIM 
can  use  either  SLOC  or  function  points  (or  both)  to  develop 
cost  and  schedule  estimates  for  software  projects.18 

•  PRICE-S  is  one  of  a  family  of  models  developed  by  PRICE  Sys¬ 
tems.'  The  current  version  of  this  model,  TruePlanning,  uses 
SLOC,  function  points,  or  POPs. 

•  The  original  SEER  for  Software  (SEER-SEM)  model  was  re¬ 
leased  in  1988  by  Galorath,  Inc.  [38].  It  is  composed  of  a 
group  of  models  working  together  to  provide  estimates  of  ef¬ 
fort,  duration,  staffing,  and  defects;  it  supports  both  SLOC 

20 

and  function  points  [39]  .' 

Most  organizations  have  determined  that  using  multiple  data  sources 
and  multiple  cost  models  can  increase  the  accuracy  of  software  cost 
estimates.  Figure  1  provides  an  overview  of  a  software  costing  exercise 
that  uses  two  estimating  tools. 


Detailed  information  on  the  current  version  of  SLIM  is  available  at 
http://www.qsm.com/  [36]. 

In  1973,  the  PRICE  Hardware  model  (PRICE-H)  was  marketed  by  RCA 
PRICE  Systems  as  the  first  widely  available  parametric  cost-estimating 
tool.  In  1976,  RCA  PRICE  Systems  released  the  PRICE  Life  Cycle 
(PRICE-L)  model  to  address  the  maintenance  or  support  costs  of  hard¬ 
ware  once  it  had  been  developed  or  produced.  The  current  version, 
TruePlanning,  is  distributed  by  PRICE  Systems  LLC.  Documentation  for 
this  model  is  available  at  the  following  website: 
http: / /www.pricesystems.com/research/white  papers /True-S-White- 

Paper-no-NDA-Required.pdf  [37]. 
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More  detailed  information  on  the  current  version  of  SEER-SEM  is  avail¬ 
able  at  http://www.galorath.com/  1381 . 


Figure  1 .  DOD  software  costing  process 
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Industry  approaches  to  data  rights  valuation 

In  practice,  suppliers  use  licenses  to  protect  proprietary  innovations 
and  to  distinguish  their  products  from  those  of  their  rivals  [40].  In 
the  absence  of  a  license,  there  is  little  incentive  for  a  technology  firm 
to  release  proprietary  information.  In  doing  so,  a  supplier  would  risk 
diluting  its  competitive  advantage  and  limiting  its  ability  to  earn  prof¬ 
its — i.e.,  economic  rents — in  the  future." 


In  a  2008  white  paper,  the  executive  director  of  Integrated  Dual-use 
Commercial  Companies  (IDCC),  Robert  Spreng,  defines  economic  rent 
as  “what  firms  earn  over  and  above  the  cost  of  the  capital  employed  in 
their  business.  The  objective  of  a  firm  is  to  increase  its  economic  rent, 
rather  than  its  profit  as  such.  A  firm,  which  increases  its  profits  but  not 
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According  to  Richard  Razgaitis,  a  senior  advisor  at  Charles  River  As¬ 
sociates, 

Virtually  every  technology-rich  commercial  business  aggres¬ 
sively  protects  its  proprietary  data.  This  proprietary  data  de¬ 
fines  the  business  and  its  potential.  These  commercial  firms 
keep  their  proprietary  data  related  to  important  commer¬ 
cial  developments  well  protected  within  the  organization. 
Normally  only  a  relatively  few  trusted  business  and  technical 
employees,  with  a  vested  interest  in  the  commercial  success 
of  the  development,  will  have  access  to  the  data  until  pro¬ 
duction  scale  up.  [42] 

For  firms  providing  software  to  DOD,  an  acceptable  price  for  addi¬ 
tional  data  rights  depends  on  the  value  of  these  rights  in  commercial 
applications  and  their  impact  on  the  market  as  a  whole  [44] .  In  this 
section,  we  review  the  range  of  tools  typically  used  by  suppliers  to  es¬ 
timate  the  value  of  software  licenses.  This  list  provides  DOD  acquisi¬ 
tions  professionals  with  background  on  how  industry  would  prepare 
to  come  to  the  bargaining  table. 

1.  The  market  approach  considers  a  range  of  published  values  for 
similar  data  [44].  In  this  approach,  value  is  estimated  by  (1) 
analyzing  similar  data  that  have  been  recently  sold  or  licensed, 
(2)  adjusting  these  observations  for  differences  in  the  timing  of 
previous  transactions  and  in  the  nature  of  the  product  in  ques¬ 
tion  [45]. 

2.  The  rating/ranking  approach  is  an  extension  of  the  market  ap¬ 
proach.  The  analyst  reviews  existing  data  licenses  for  similar 
technologies  and  ranks  their  observations  on  the  basis  of  fac¬ 
tors  common  to  all  licenses.  Examples  of  such  factors  are  the 
nature  of  protection,  the  scope  of  exclusivity,  and  the  extent  of 
improvement  attributable  to  the  licensed  information  [42]. 


its  economic  rent — as  through  investments  or  acquisitions  which  yield 
less  than  the  cost  of  capital — destroys  value.  Economic  rent  is  the  meas¬ 
ure  of  the  competitive  advantage,  which  effective,  established  firms  en¬ 
joy,  and  competitive  advantage  is  the  only  means  by  which  companies  in 
contestable  markets  can  earn  economic  rents”  [41]. 


3.  The  rule  of  thumb  approach  (such  as  the  25-percent  rule  and  oth- 
er  similar  rules)  apportions  anticipated  profits"'  from  the 
commercial  use  of  the  data  between  the  seller  and  buyer  [46], 
[47]. 

4.  The  approach  using  discounted  cash-flow  analysis  with  risk-adjusted 
hurdle  rates 3  focuses  on  the  present  value  of  the  expected  in¬ 
come  to  be  earned  from  the  subject  data.  When  using  this  ap¬ 
proach,  it  is  important  that  the  projected  income  stream  be 
accessed  accurately  and  that  the  projected  stream  be  consid¬ 
ered  consistent  and  reliable  [44] . 

5.  The  advanced  tools  approach  is  an  extension  of  the  discounted 
cash  flow  method.  It  applies  statistical  methods,  such  as  Monte 
Carlo  simulations,  to  discounted  cash-flow  models  in  order  to 
test  the  impact  of  possible  license  terms  on  the  expected  out¬ 
comes  of  the  agreement  [49]. 

6.  The  relief  of  royalty  approach  calculates  the  present  value  of  a 
stream  of  royalties  that  the  technical  data  or  computer  software 
would  have  received  using  comparable  historical  data  [50], 
[51]. 

7.  The  cost  approach  estimates  the  value  of  data  by  analyzing  the 
cost  to  obtain  an  alternative  capability  [46],  [47].  One  method 
of  estimating  the  cost  is  to  compute  the  expected  Remaining 
Useful  Life  (RUL)  for  the  software  in  question.  Practitioners 
note  that  a  variety  of  factors  affect  both  the  overall  value  of  the 
data  and  RUL.  The  following  are  examples  of  such  factors: 


Anticipated  profit  is  the  anticipated  income  flow  discounted.  Income 
can  be  influenced  by  a  number  of  factors,  including  sales  volume,  per 
unit  price,  input  costs,  competition,  overall  economic  climate,  and  gov¬ 
ernment  regulations.  The  discount  represents  the  subjective  risk  of  that 
income  flow  to  its  owner  (investment  value) .  The  investment  value  dis¬ 
count  rate  is  usually  lower  than  the  market  value  discount  rate,  resulting 
in  a  higher  present  investment  value  than  present  market  value. 

The  hurdle  rate  is  the  minimum  rate  of  return  on  a  project  or  invest¬ 
ment  required  by  a  manager  or  investor.  To  compensate  for  risk,  the 
hurdle  rate  increases  with  the  risk  of  the  project.  It  is  usually  calculated 
as  the  cost  of  the  capital  involved  adjusted  by  a  risk  factor. 
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a.  Expected  vise  of  the  subject  asset 

b.  Required  maintenance  expenditures  to  prolong  economic 
life 

c.  Legal  life  and  renewal  provisions  (if  applicable) 

d.  Contractual  issues,  such  as  licensing  and  transfer  price 

e.  Competing  and  emerging  technology 

f.  Market  demand 

g.  Other  factors,  such  as  industry  volatility,  unexpected 
changes  in  distribution  channels  or  legislative  actions 

h.  Professional  judgment  [52] 

Most  suppliers  use  the  advanced  tools  approach  in  valuing  software  li¬ 
censes.  However,  this  method  will  not  help  DOD  acquisitions  profes¬ 
sionals  evaluate  pricing  proposals  from  would-be  suppliers.  The 
advanced  tools  approach  assumes  that  it  is  possible  to  estimate  a  cash 
flow  stream  that  is  logically  separate  from  the  negotiations  at  hand. 
This  is  not  the  case  when  DOD  negotiates  with  potential  suppliers:  it 
is  these  very  negotiations  that  will  determine  the  cash  flow  stream  ac¬ 
cruing  to  the  data.  Thus  anticipated  cash  flow  cannot  be  used  as  an 
independent  evaluation  criterion  for  price  quotes. 

As  we  see  in  the  next  chapter,  the  cost  approach  offers  a  means  of 
avoiding  this  conundrum. 


3  Negotiating  for  additional  rights 

As  noted  in  the  previous  chapter,  suppliers  must  consider  how  a 
transaction  involving  data  will  affect  other  business  ventures — both 
current  and  future.  The  more  important  the  intellectual  property  is 
to  the  firm’s  other  business  ventures,  the  more  the  firm  will  try  to  lim¬ 
it  the  release  of  this  information,  and  the  higher  the  value  they  will 
place  on  the  data.  In  contrast,  DFARS  requires  DOD  to  focus  primari¬ 
ly  on  the  nature  of  the  data  and  source  of  funds  used  to  develop 
them. 

Figure  2  illustrates  the  combination  of  these  perspectives — and  iden¬ 
tifies  four  general  scenarios  or  cases.  As  we  see  below,  only  cases  3 
and  4  are  likely  to  lead  to  situations  in  which  the  would-be  supplier  is 
reluctant  to  negotiate — or  is  likely  to  quote  a  prohibitively  high  li¬ 
censing  fee. 


Figure  2.  Contractor's  approach  to  data  rights 
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Case  1:  Low  market  value,  no  DOD  funding.  This  scenario  is  unlikely  to 
pose  problems.  Because  the  data  have  few  commercial  uses,  the  sup¬ 
plier  will  likely  be  interested  in  negotiating.  Since  DOD  has  no  direct 
investment  in  the  development  of  the  data,  it  should  be  reasonably 
easy  to  find  common  ground. 

Case  2:  Low  market  value,  mixed  DOD /private  funding.  Under  DEARS, 
DOD  obtains  has  government  purpose  rights  to  technical  data  and 
computer  software  that  were  developed  with  a  combination  of  private 
and  government  funds.  With  no  alternative  customers,  suppliers 
should  be  willing  to  negotiate  a  mutually  agreeable  licensing  ar¬ 
ranged  for  the  data  rights  that  do  not  automatically  convey  when  in¬ 
novations  are  substantially  financed  by  the  government.  When  there 
are  few  commercial  customers  for  the  product  in  question,  the  gov¬ 
ernment  is  in  a  relatively  strong  bargaining  position. 

Case  3:  High  market  value,  mixed  DOD/private  funding.  This  combina¬ 
tion  is  likely  to  cause  conflict  during  negotiations.  The  contractor  has 
a  strong  incentive  to  create  market  barriers  and  enhance  the  value  of 
the  firm  by  creating  vendor  lock.  In  contrast,  DOD  is  likely  to  argue 
that  it  has  rights  to  the  data  because  it  funded  much  of  the  develop¬ 
ment.  For  this  scenario,  the  details  of  the  deliverables  specified  in  the 
contract  are  likely  to  have  a  significant  impact  on  markets  in  the  fu¬ 
ture. 

Case  4:  High  market  value,  no  DOD  funding.  When  DOD  is  not  directly 
paying  for  product  development,  suppliers  rely  on  conventional  intel¬ 
lectual  property  rights  as  the  primary  means  to  recoup  nonrecurring 
costs  and  seek  profit  [43].  Examples  of  this  scenario  include  “pre¬ 
existing”  intellectual  property  that  is  essential  to  the  firm’s  business 
and  “commercial-off-the-shelf’  (COTS)  products  in  general.  Suppli¬ 
ers  in  this  scenario  generally  have  market  power  and  are  in  a  strong 
bargaining  position. 


COTS  is  a  term  used  to  define  a  non-developmental  item  (NDI)  of  sup¬ 
ply  that  is  both  commercial  and  sold  in  substantial  quantities  in  the 
commercial  marketplace  and  that  can  be  procured  or  used  under  gov¬ 
ernment  contract  in  the  same  precise  form  as  available  to  the  general 
public. 


In  the  next  section  we  examine  the  relationship  between  the  market 
value  of  data  and  the  benefit  to  the  government  of  paying  for  addi¬ 
tional  license  rights. 

The  benefit  to  DOD  of  data  rights  acquisition:  an  illustration 

Below  we  present  a  numerical  example  to  illustrate  how  data  rights 
negotiations  affect  the  contracting  process.  Specifically,  we  describe  a 
two-period  bargaining  problem  in  which  a  DOD  program  office  con¬ 
ducts  a  repeated  acquisition.  (A  more  general  version  of  this  bargain¬ 
ing  “game”  appears  in  appendix  C.) 

The  acquisition  involves  multiple  types  of  data  and  data  rights,  some 
of  which  will  convey  automatically  to  DOD.  Access  to  the  remaining 
data  will  require  negotiations  for  appropriate  licenses.  (We  refer  to 
the  full  set  of  data  rights  involved  in  the  acquisition  as  a  “data  pack¬ 
age.”)  We  assume  that  the  bargaining  environment  is  characterized  as 
case  4  in  figure  2  (i.e.,  a  scenario  in  which  suppliers  have  market 
power  and  are  in  a  strong  bargaining  position) . 

To  highlight  the  basic  structure  of  the  government’s  bargaining  prob¬ 
lem,  we  assume  that  DOD  wants  to  acquire  a  product  during  each  of 
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two  periods.  We  also  assume  that  contract  execution  requires  both 
design  and  production  effort  during  period  1,  but  only  production 
effort  in  period  2,  along  with  access  to  the  data  package  created  in 
period  1. 

We  suppose  that  the  full  data  package  is  transferrable  by  license  to 
one  or  more  alternative  suppliers  in  period  2 — as  long  as  such  a  pro¬ 
vision  is  included  in  the  terms  of  the  period  1  contract.  Access  to  the 
data  package  as  government-furnished  equipment  (GFE)  will  lower 
period  2  production  costs  for  any  new  supplier.  However,  treating  the 

data  package  as  a  period  2  deliverable  will  increase  period  1  produc- 
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tion  costs  for  the  period  1  supplier." 


A  similar  scenario  would  apply  to  service  contracts. 

For  example,  ensuring  that  technical  data  are  transferrable  may  require 
additional  documentation,  record-keeping,  and  testing. 
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We  rely  on  competition — however  limited — to  impose  some  form  of 
price  discipline.  Specifically,  for  period  1,  we  assume  that  bidding  will 
reflect  competition  among  potential  suppliers.  For  period  2,  we  as¬ 
sume  that  the  successful  period  1  bidder  will  not  be  able  to  charge 
more  than  the  bid  submitted  by  the  next  most  capable  alternative  pe¬ 
riod  2  supplier. 

Defining  the  potential  value  of  technical  data  package  to  the  gov¬ 
ernment  requires  further  assumptions  about  cost.  We  assume  the  fol¬ 
lowing  for  period  1: 

•  The  winning  bid  for  period  1  development  and  production  is 

27 

$150  when  no  technical  data  package  is  requested.' 

•  The  period  1  cost  to  the  winning  bidder  of  preparing  a  tech¬ 
nical  data  package  is  $15. 

For  period  2,  we  assume  the  following: 

•  The  production  cost  is  $75  if  the  period  1  supplier  (i.e.,  the 
incumbent)  wins  the  period  2  contract. 

•  The  production  cost  is  $125  if  a  new  supplier  is  chosen  but 
does  not  receive  a  technical  data  package  as  GFE. 

•  The  production  cost  is  $90  if  a  new  supplier  is  chosen  and  is 
provided  with  the  technical  data  package  developed  in  period 
1. 

In  other  words,  we  assume  that  access  to  a  technical  data  package  al¬ 
lows  a  new  supplier  to  save  $35  in  period  2  production  costs. 

Figure  3  illustrates  how  the  sequence  of  prices  depends  on  the  gov¬ 
ernment’s  decision  to  request  a  technical  data  package  as  a  delivera¬ 
ble. 
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This  value  is  determined  by  competitive  bidding  among  qualified  sup¬ 
pliers  in  period  1 . 


Figure  3.  Contract  costs  to  the  government 


Issue  RFP 


DOD  defines 
CDRLs 


First  Second 

Contract  Contract 


o0<N  Pay  $150 

j 

l _ 


Hay 

$150+$15+p 


Pay  $125 

_ _ J 


Pay  $90 

£ _ ✓ 


The  next  step  is  to  compute  the  range  of  prices  for  the  technical  data 
package  that  would  be  acceptable  to  both  the  government  and  peri¬ 
od  1  bidders.  To  solve  this  bargaining  game,  we  start  in  period  2  and 
work  backwards. 

As  mentioned  above,  we  assume  that  competition  with  new  suppliers 
determines  the  period  2  cost  to  the  government  for  the  product  in 
question.  In  our  example,  no  one  would  bid  less  than  $125  in  period 
2  when  no  technical  data  package  is  available.  To  see  why,  consider 
the  incentives  for  both  potential  period  2  suppliers  and  the  incum¬ 
bent  supplier  from  period  1  in  these  circumstances. 

•  Potential  new  suppliers  would  lose  money  if  they  bid  any  less 
than  $125  without  access  to  a  technical  data  package. 

•  The  incumbent  from  period  1  has  no  incentive  to  underbid 
the  period  2  competition. 

Since  more  than  one  supplier  would  be  willing  to  provide  the  prod¬ 
uct  in  question  for  at  least  $125,  we  assume  that  this  is  the  outcome  of 
the  solicitation  process  in  period  2. 

In  contrast,  if  a  technical  data  package  is  available,  then  no  one 
would  bid  less  than  $90.  To  see  why,  consider  the  bidding  incentives 
in  this  alternative  scenario. 
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•  Potential  new  suppliers  would  lose  money  if  they  bid  any  less 
than  $90  when  they  have  access  to  a  technical  data  package. 

•  The  incumbent  from  period  1  has  no  incentive  to  underbid 
the  competition. 

Thus  we  assume  that  $90  is  the  outcome  of  the  period  2  solicitation 
process  in  this  scenario. 

Once  we  have  defined  the  range  of  period  2  outcomes,  we  can  move 
back  in  time  to  analyze  the  period  1  bidding  problem  that  the  gov¬ 
ernment  must  solve  in  period  1.  We  start  by  computing  the  maximum 
amount  of  money  that  the  government  would  be  willing  to  pay  to  li¬ 
cense  the  technical  data  package. 

If  a  technical  data  package  is  not  licensed,  then  the  total  cost  to  the 
government  is  the  sum  of  the  winning  bids  in  each  period: 

Period  1  bid  +  Period  2  bid  =  $150  +  $125  =  $275  (1) 

If  a  technical  data  package  is  licensed,  then  the  total  cost  for  the  pro¬ 
ject  (apart  from  licensing  fees)  is  again  the  sum  of  the  winning  bids — 
including  the  added  cost  of  package  preparation: 

Period  1  bid  +  Period  2  bid  =  $150  +  $15  +  $90  =  $255  (2) 

Requesting  a  technical  data  package  as  a  deliverable  would  reduce 
the  government’s  total  cost  as  long  as  the  amount  paid  (p)  for  the  li¬ 
cense  satisfied  the  following  restriction: 

255  +  p  <  $275  (3) 

Rearranging  equation  (4)  yields  a  maximum  value  for  p: 

p  <  $275  -  $255  =  $20  (4) 

In  other  words,  the  government’s  willingness  to  pay  for  a  license  is 
equal  to  the  value  of  the  license  to  a  new  supplier  ($35  in  this  case) 
minus  the  cost  of  preparing  the  technical  data  package  ($15  in  this 
case).  If  the  government  paid  any  more  than  $20  for  this  license,  the 
decision  to  request  a  technical  data  package  would  raise,  rather  than 
lower,  the  total  cost  of  the  project  described  here. 


Data  rights  acquisition  in  practice 

The  numerical  example  above  highlights  the  source  of  value  to  DOD 
of  licensing  data:  in  our  model,  life-cycle  cost  falls  only  if  licensed  da¬ 
ta  enables  alternative  suppliers  to  lower  their  production  costs  and  to 
bid  more  aggressively  in  future  solicitations.  Thus,  the  value  to  DOD 
of  an  expanded  license  is  determined  by  the  extent  of  this  cost  sav¬ 
ing. 

The  software  cost  models  in  chapter  2  can,  in  principle,  provide  an 
upper  limit  on  the  amount  that  DOD  would  be  willing  to  pay  for  ad¬ 
ditional  data  rights  licenses.  We  assume  that  such  licenses  would  ena¬ 
ble  alternative  suppliers  to  avoid  the  cost  of  developing  the 
information  in-house  and  that  competition  would  force  these  suppli¬ 
ers  to  pass  the  savings  on  to  DOD  in  the  form  of  lower  bids.  In  such 
circumstances,  a  software  cost  model  could  be  used  to  estimate  the 
expenditures  avoided  when  an  alternative  supplier  has  access  to  soft¬ 
ware  code.  This  amount  is  also  the  maximum  savings  that  could  be 
realized  by  DOD. 

Our  model  indicates  when  potential  suppliers  may  either  choose  not 
to  bid  or  decide  to  refrain  from  quoting  a  price  for  additional  data 
rights  licenses.  In  the  numerical  example  above,  the  period  1  suppli¬ 
er  would  receive  at  most  $20  as  a  license  fee.  This  may  not  be  suffi¬ 
cient  to  offset  the  revenue  that  the  firm  expects  to  lose  in  its  other 
lines  of  business — such  as  domestic  commercial  or  international 
sales — once  the  license  has  been  granted.  In  such  cases,  it  is  likely 
that  the  government’s  willingness-to-pay  will  be  smaller  than  the  sup¬ 
plier’s  willingness-to-sell.  Thus  no  additional  data  rights  licenses  will 
be  acquired. 

The  model  provides  a  word  of  caution  about  the  impact  of  technical 
data  licenses  on  life-cycle  costs.  In  the  numerical  example,  if  the  gov¬ 
ernment  agreed  to  a  license  fee  equal  to  its  maximum  willingness-to- 
pay,  then  the  total  acquisition  cost  would  be  the  same  whether  a  li¬ 
cense  fee  was  paid  or  not. 
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This  page  intentionally  left  blank. 


4  Conclusions  and  recommendations 


In  DOD  software  acquisitions,  the  right  to  use,  modify,  reproduce,  re¬ 
lease,  perform,  display  or  disclose  computer  software  (and  computer 
software  documentation)  has  become  an  important  topic  in  contract 
negotiations.  Federal  law  and  regulations  define  the  starting  point  for 
these  negotiations.  For  software,  this  starting  point  includes  a  default 
assignment  of  data  rights  to  both  the  government  and  the  supplier  (s) 
based  on  the  source  of  funding.  We  observe  that 

•  DOD  typically  obtains  a  license  to  use  software  developed  un¬ 
der  contract,  not  ownership  of  the  code  itself.  (DOD  does  not 
own  the  code  unless  it  was  developed  by  a  government  em¬ 
ployee.) 

•  For  most  types  of  data,  the  default  terms  of  the  license  de¬ 
pend  on  the  source  (s)  of  funding  used  to  pay  for  develop¬ 
ment  costs  of  the  item  or  component  to  which  the  data 
relates.  The  actual  terms  of  the  license  are  determined  by  ne¬ 
gotiation. 

•  By  default,  DOD  receives  unlimited  rights  to  certain  catego¬ 
ries  of  data,  including 

o  form,  fit,  and  function  data; 

o  data  that  are  necessary  for  operation,  maintenance,  in¬ 
stallation,  and  training;  and 

o  computer  software  documentation  required  to  be  de¬ 
livered  under  a  government  contract. 

During  negotiations,  both  government  and  industry  need  to  distin¬ 
guish  between  data  rights  and  software  as  deliverables.  From  a  DOD 
perspective,  the  value  of  software  is  determined  by  its  capabilities;  the 
value  of  data  is  determined  by  its  anticipated  impact  on  future  com¬ 
petition. 


29 


DOD  should  not  pay  more  today  in  license  fees  for  expanded  data 
rights  than  the  benefit  it  expects  to  derive  from  using  the  rights  in 
the  future.  This  amount  would  generally  be  the  present  value  of  ex¬ 
pected  future  cost  savings.  (If  DOD  paid  more  than  the  present  value 
of  future  cost  savings,  it  would  have  overcompensated  industry:  a 
$100  payment  made  today  to  compensate  for  a  future  loss  of  this 
amount  will  be  worth  more  than  $100  when  the  loss  actually  occurs.) 

We  found  that  the  value  to  DOD  of  expanded  data  rights  depends  on 
the  usefulness  of  the  information  to  alternative  suppliers  and  the  im¬ 
plied  impact  on  prices  in  the  future.  For  example,  access  to  a  tech¬ 
nical  data  package  as  GFE, 

•  may  allow  future  competitors  to  avoid  inventing  alternatives  to 
existing  techniques;  and 

•  may  allow  future  competitors  to  use  prior  innovations  without 
paying  royalties  or  incurring  test  and  evaluation  costs. 

Overall,  DOD’s  maximum  willingness  to  pay  for  expanded  licenses  is 
greater 


•  when  the  information  is  more  useful  to  alternative  suppliers; 

•  when  the  cost  to  the  original  developer  of  making  data  rights 
transferrable  is  lower;  and 

•  when  the  impact  on  future  prices  is  greatest. 

Software  cost  estimating  tools  may  be  used  to  set  an  upper  limit  on 
DOD’s  willingness  to  pay  for  expanded  license  rights.  DOD  analysts 
will  need  to  answer  the  following  types  of  questions  in  the  cost  esti¬ 
mation  process: 

•  What  development  activities  do  alternative  suppliers  avoid 
when  given  access  to  existing  computer  software  and  comput¬ 
er  software  documentation  as  GFE? 

•  To  what  extent  will  these  cost  savings  be  passed  on  to  the  gov¬ 
ernment? 

•  What  added  preparation  costs  are  incurred  by  the  original  de¬ 
veloper  to  make  the  data  rights  transferrable? 


Once  svich  questions  have  been  answered,  conventional  cost  estima¬ 
tion  tools  can  be  used  to  estimate  the  cost  savings. 

We  note  that  the  separate  acquisition  of  additional  data  rights  will  not 

always  lead  to  future  cost  savings.  To  determine  the  likely  benefit  of 

broader  licenses,  DOD  analysts  need  to  address  the  following  types  of 
.28 
questions: 

•  What  data  rights  does  the  DEARS  automatically  provide  to 
DOD? 

•  Will  access  to  the  additional  rights  requested  actually  allow  for 
more  effective  competition  in  the  future? 

•  What  is  the  net  effect  on  the  DOD  “top  line”  once  the  price  of 
the  expanded  license  and  “transferability  costs”  are  taken  into 
account? 

Our  analysis  indicates  that  acquiring  data  rights  will  provide  less  ben¬ 
efit  to  DOD 

•  when  DEARS  already  provides  DOD  with  substantial  access  to 
the  data  in  question; 

•  when  making  the  data  rights  transferrable  requires  additional 
costly  documentation  and  testing  to  ensure  compatibility; 

•  when  the  data  covered  by  the  data  rights  must  be  used  in  con¬ 
junction  with  a  separate,  proprietary  technology; 

•  when  there  are  few  alternative  suppliers  capable  of  bringing 
“in-house”  the  technology  covered  by  the  data  rights;  and 

•  when  sales  to  DOD  represent  a  relatively  small  part  of  a  suppli¬ 
er’s  customer  base. 


See  the  OSA  Contract  Guidebook  ([43],  p.  119)  for  a  related  list  of  ques¬ 
tions  to  be  used  in  a  data  rights  assessment. 
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Recent  guidance  provides  useful  advice  for  acquisitions  officials  on 
when  it  is  advisable  to  obtain  a  technical  data  license.  We  highlight 
four  recommendations: 

•  Include  an  explicit  request  for  data  rights  pricing  in  solicita¬ 
tions.  (The  OSA  Contract  Guidebook  ([43],  pp.  7,  56-58)  pro¬ 
vides  examples  of  how  to  specify  such  requests.) 

•  Identify  data  rights  as  explicit  deliverables.  (The  OSA  Contract 
Guidebook  ([43],  appendix  11)  provides  examples  of  formal 
contract  data  requirements  lists  (CDRLs.) 

•  Include  appropriate  DEARS  clauses  in  solicitation  to  establish 
contracting  authority.  (The  table  on  page  C-l  of  the  OSA  Con¬ 
tract  Guidebook  [43]  provides  recommendations  on  which 
clauses  to  include  in  different  types  of  solicitations.  We  repro¬ 
duce  this  information  as  Error!  Reference  source  not  found, 
in  appendix  A.) 

•  Indicate  how  conformity  with  requirements  will  be  validated. 
(The  OSA  Contract  Guidebook  ([43],  pp.  28-29)  recommends  a 
Modular  Open  Systems  Approach  to  validating  conformance 
and  provides  sample  solicitation  clauses.) 


Appendix  A:  Definitions  and  categories  of  data 
rights 

Definitions 


DEARS  Sections  227  and  252.227  are  the  primary  DOD  sources  of 
contract  language  used  in  acquisitions  involving  data  rights.  In  this 
paper,  we  rely  on  the  following  definitions: 

•  “Technical  data”  is  defined  by  Defense  Federal  Acquisition 
Supplement  (DFARS)  [54]  §  252.227-7013  (a)  (14)  as  recorded 
information,  regardless  of  the  form  or  method  of  recording, 
of  a  scientific  or  technical  nature  (including  computer  soft¬ 
ware  documentation),  excluding  computer  software  or  data 
incidental  to  contract  administration,  such  as  financial  or 
management  information. 

•  “Computer  software”  is  defined  by  DFARS  [54]  §§  252.227- 
7013(a)(3)  and  252.227-7014(a)  (4)  as  computer  programs, 
source  code,  source  code  listings,  object  code  listings,  design 
details,  algorithms,  processes,  flow  charts,  formulae  and  rela¬ 
tion  material  that  would  enable  the  software  to  be  repro¬ 
duced,  recreated,  or  recompiled,  but  excludes  computer 
databases  or  computer  software  documentation. 

•  “Commercial  technical  data”  is  defined  by  DFARS  [54] 
§  252.227-7015(a)  as  recorded  information,  regardless  of  the 
form  or  method  of  the  recording,  of  a  scientific  or  technical 
nature  (including  computer  software  documentation).  The 
term  does  not  include  computer  software  or  data  incidental  to 
contract  administration,  such  as  financial  or  management  in¬ 
formation. 
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•  “Commercial  software”  is  defined  by  DFARS  [54]  §  252.227- 
7014(a).  It  refers  to  software  developed  or  regularly  used  for 
non-governmental  purposes  which 

o  has  been  sold,  leased,  or  licensed  to  the  public; 

o  has  been  offered  for  sale,  lease,  or  license  to  the  pub¬ 
lic; 

o  has  not  been  offered,  sold,  leased,  or  licensed  to  the 
public  but  will  be  available  for  commercial  sale,  lease, 
or  license  in  time  to  satisfy  the  delivery  requirements 
of  this  contract;  or 

o  satisfies  a  criterion  above  and  would  require  only  mi¬ 
nor  modification  to  meet  the  requirements  of  a  con¬ 
tract. 

A  matrix  that  shows  when  to  incorporate  specific  DFARS  clauses  is 
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provided  in  table  1,  below. 

Table  1 .  Guidance  on  incorporating  DFARS  data  rights  clauses/provisions 


When  to  incorporate  DFARS  clauses/ provisions 

DFARS  clause  252.277-  7013  7014  7015  7016  7017  7019  7028  7030  7037 


Mandatory  for  TD  if  noncom¬ 
mercial  ICP  is  to  be  delivered 

X 

X 

X 

X 

X 

X 

Mandatory  if  noncommercial  CS 
is  to  be  delivered 

Mandatory  if  TD  for  commercial 
items  is  to  be  delivered 

X 

X 

X 

X 

X 

X 

X 

Strongly  recommended  in  all 
solicitations 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Strongly  recommended  in  all 
contracts 

X 

X 

X 

X 

X 

X 

X 

Technical  Data  =  TD  Computer  Software  =  CS  Item,  Component,  Process  =  ICP 


Computer  Software  Documentation  =  CSD  (TD) 
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This  table  is  reproduced  from  p.  C-l  of  the  Contract  Guidebook  for  Program 
Managers,  V.0.1,  which  was  prepared  by  the  DOD  Open  Systems  Archi¬ 
tecture  Data  Rights  Team  [43] . 


Categories  of  data  rights 

DOD  may  acquire  four  basic  types  of  rights  to  noncommercial  tech¬ 
nical  data: 

•  Unlimited  Rights :  With  respect  to  noncommercial  technical  da¬ 
ta  and  computer  software,  “unlimited  rights”  are  defined  as 
the  right  to  “use,  modify,  reproduce,  perform,  display,  release, 
or  disclose”  technical  data,  computer  software  and  computer 
software  documentation  “in  whole  or  in  part,  in  any  manner, 
and  for  any  purpose  whatsoever,  and  to  have  or  authorize 
others  to  do  so.”  (DEARS  [54]  §§  252.227-7013(a)  (16)  and 
252.227-7014(a)  (15) ) . 

•  Government  Purpose  Rights :  With  respect  to  noncommercial 

technical  data  and  computer  software,  “government  purpose 
rights”  are  defined  as  the  right  to  “use,  modify,  reproduce,  re¬ 
lease,  perform,  display,  or  disclose”  within  the  government 
without  restriction  and  the  right  to  release  or  disclose  outside 
the  government  for  U.S.  government  purposes.  (Here,  “gov¬ 
ernment  purpose”  refers  to  any  activity  in  which  the  U.S.  gov¬ 
ernment  is  a  party;  this  includes  holding  competitive 
procurements,  but  excludes  modification,  use,  release,  or  dis¬ 
closure  for  commercial  purposes.)  After  five  years  (or  some 
other  period  negotiated  by  the  parties),  the  government’s 
rights  in  such  noncommercial  technical  data  or  computer 
software  are  automatically  upgraded  to  Unlimited  Rights 
(DEARS  [54]  §§  252.227-7013(a)  (13)  and  252.227- 

7014(a) (12)). 

•  Limited  Rights:  With  respect  to  noncommercial  technical  data, 
‘“limited  rights’  means  the  right  use,  modify,  reproduce,  re¬ 
lease,  perform,  display,  or  disclose  technical  data,  in  whole  or 
in  part,  within  the  Government”  and  the  right  to  release  out¬ 
side  the  government  only  if 

o  the  recipient  requires  such  data  to  perform  emergency 
repair  and  overhaul  or  if  the  release  or  disclosure  will 
be  to  a  “covered  Government  support  contractor”  or 
to  a  foreign  government.  (If  the  release  or  disclosure  is 
to  a  foreign  government,  then  the  data  released  must 
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be  other  than  detailed  manufacturing  or  process  data, 
must  be  in  the  interest  of  the  U.S.  government,  and 
must  be  required  for  evaluation  or  informational  pur¬ 
poses); 

o  the  recipient’s  contract  contains  DEARS  [54]  § 

252.227-7025;  and 

o  the  government  notifies  the  owner  of  that  technical 
data  of  such  reproduction,  release,  disclosure,  or  use. 

If  technical  data  are  provided  to  a  recipient  for  purposes  of 
emergency  repair  or  overhaul,  the  recipient  is  required  to  de¬ 
stroy  the  technical  data  and  all  copies  in  its  possession 
promptly  following  completion  of  the  emergency  re¬ 
pair/overhaul  (DEARS  [54]  §  252.227-7013  (a)  (14)). 

Specifically  Negotiated  License  Rights:  Parties  can  modify  the 
standard  license  rights  granted  to  the  government  or  obtain 
rights  under  circumstances  where  the  government  would  or¬ 
dinarily  not  be  entitled  to  specific  rights.  Noncommercial 
technical  data  or  computer  software  marked  with  “Specifically 
Negotiated  License  Rights”  cannot  be  released  outside  the 
government  unless 

o  (1)  the  conditions  specified  in  that  license — which 
should  be  incorporated  by  reference  into  the  contract 
and  physically  attached  to  the  contract  referenced  in 
that  restrictive  marking — have  been  satisfied; 

o  (2)  the  recipient’s  contract  contains  DEARS  [54]  § 

252.227- 7025;  and 

o  (3)  the  recipient  has  signed  the  Use  and  Non- 
Disclosure  Agreement  found  at  DEARS  [54]  § 

227.7103-7(c)  as  modified  by  DEARS  [54]  §  252.227- 
7025(b)(3).  (DEARS  [54]  §§  252.227-7013(b)  (4)  and 

252.227- 7014(b)  (4)). 

In  some  cases,  the  government  may  accept  less  than  Unlim¬ 
ited  Rights  or  Government  Purpose  Rights  in  noncommercial 
technical  data  or  computer  software,  but  it  cannot  accept  less 
than  Limited  Rights  in  noncommercial  technical  data  or  Re- 


stricted  Rights  in  noncommercial  computer  software.  If,  how¬ 
ever,  the  technical  data  are  of  a  certain  type,  the  contractor 
may  never  restrict  the  government  from  releasing  or  disclos¬ 
ing  such  technical  data  outside  the  government,  and  the  gov¬ 
ernment  is  prohibited  from  negotiating  away  its  Unlimited 
Rights  to  use,  release,  or  disclose  such  technical  data. 

DEARS  does  not  provide  a  clause  defining  the  government’s  rights  in 
commercial  computer  software  (including  Open  Source  Software 
(OSS))  [55].  Commercial  software  is  generally  acquired  under  the 
same  type  of  license  customarily  provided  to  the  public  (provided 
that  those  licenses  are  consistent  with  federal  procurement  law  and 
otherwise  satisfy  user  needs) .  Such  software  is  obtained  competitively, 
to  the  maximum  extent  practicable,  using  firm-fixed-price  contracts 
or  firm-fixed-price  orders  under  available  pricing  schedules  [56] . 


37 


This  page  intentionally  left  blank 


Appendix  B:  Market  value  for  non-commercial 
software 


There  are  two  basic  sources  of  market  value  for  non-commercial 
software: 

•  Non-commercial  software  that  was  initially  developed  for  gov¬ 
ernment  purposes  may  evolve  into  a  “commercializable”  prod¬ 
uct  in  the  future.  Examples  of  this  situation  include  specialized 
semiconductor  chips,  programmable  machine  tools,  and  inter¬ 
net  protocols. 

•  Non-commercial  software  is  likely  to  include  commercial  com¬ 
ponents. 

Either  of  these  scenarios  is  sufficient  to  establish  a  link  between  a 
supplier’s  profit  and  the  scope  of  the  data  rights  provided  to  DOD  for 
non-commercial  software;  we  discuss  each  in  turn  below. 

With  respect  to  commercializing  non-commercial  software,  we  note 
that  suppliers  supporting  federal  programs  are  actively  seeking  op¬ 
portunities  to  commercialize  non-commercial  code.  The  benefits 


In  a  1993  study,  the  Congressional  Office  of  Technology  Assessment  found 
that 

there  is  enough  commonality  in  military  and  commercial 
applications  of  some  critical  core  technologies  that  defense 
spending  over  the  years  has  strongly  supported  both.  It  has 
produced  semiconductor  chips  of  various  kinds  that  find 
uses  in  autos  and  engineering  work  stations  as  well  as  guid¬ 
ed  missiles;  programmable  machine  tools  that  can  make 
parts  for  fighter  aircraft  or  lawn  mowers,  tractors,  and 
commercial  airliners;  computational  techniques  that  model 
nuclear  explosions  or  analyze  what  happens  to  cars  in 
crashes.  ( [62] ,  p.  4) 
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In  a  1994  study  sponsored  by  DOD,  Ferguson  and  DeRiso  argued  that 
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to  the  supplier  in  terms  of  revenue  and  market  position  are  potential¬ 
ly  quite  large.  The  successful  commercialization  of  code  initially  writ¬ 
ten  for  a  government  contract  is  likely  to  shorten  the  amount  of  time 
it  takes  to  bring  a  new  product  to  market,  reduce  development  costs, 
and  increase  product  quality  (since  the  code  has  already  been  test¬ 
ed),  thereby  providing  the  supplier  with  a  unique  competitive  ad¬ 
vantage.  In  today’s  market — where  firm  valuation  may  depend 
directly  on  its  portfolio  of  software  products — the  ability  to  transition 
non-commercial  code  to  support  or  create  a  commercial  product  has 
become  a  raison  d’etre  for  suppliers.  Thus,  the  valuation  assigned  to 
licenses  for  additional  data  rights  has  become  more  complex,  as  sup¬ 
pliers  comprehend  the  future  benefits  of  non-commercial  code  with¬ 
in  the  commercial  market. 

We  next  review  the  use  of  commercial  components  in  non¬ 
commercial  code  in  order  to  illustrate  its  importance  for  data  rights 
negotiations.  We  note  that  software,  both  commercial  and  non¬ 
commercial,  consists  of  modules  or  components.  Many  of  these  com¬ 
ponents  implement  features  that  are  common  to  a  wide  variety  of  ap¬ 
plications.  Examples  of  such  reusable  components  include 

•  sorting  algorithms 

•  equation  solving  methods 

•  signal  processing  components 

•  data  compression  and  format  conversion  algorithms 

•  security  features  (encryption,  biometrics,  etc.) 


Industry,  with  the  move  toward  just-in-time  ordering  and  ag¬ 
ile  manufacturing,  is  beginning  to  experience  the  need  for 
large  near  real-time  command  and  control  systems  similar 
to  those  long  used  by  the  DoD.  Indeed,  some  industries, 
such  as  communications  and  manufacturing,  have  already 
developed  systems  similar  to  those  used  for  tactical  military 
command  and  control.  These  systems,  depending  on  the 
application  domain,  consist  of  between  60%  and  80%  infra¬ 
structure  (database,  user  interface,  etc.).  The  market  for 
this  infrastructure  will  thus  grow  from  one  customer  (the 
DoD)  to  many.  ([63],  p.  10) 


file  indexing  and  search  methods 


• 

•  user  interface  conventions 

•  mapping  and  location  tracking  methods 

•  artificial  intelligence  modules;  3D  simulation  techniques 

•  queue  processing  and  time-stamping  functions 

It  takes  time  and  talent  to  write  efficient  code  for  components  of  this 
sort.  A  potential  DOD  supplier  that  has  privileged  access  to  one  or 
more  of  these  components  has  an  advantage  when  responding  to 
both  government  and  commercial  solicitations.  The  following  table 
lists  potential  sources  of  reusable  software  components  and  indicates 
the  default  license  that  would  be  delivered  under  the  DFARS. 


Table  2.  Software  components  and  their  associated  rights 


Source  of  component 


Associated  rights 


A 


Code  written  using  only  funds  May  have  use  in  future  contracts;  future  value  to  prime  contractor 
from  the  DOD  contract  in  will  depend  on  terms  negotiated  for  the  current  contract.  Govern- 
question  ment  will  receive  unlimited  rights  in  code  identified  as  a  deliverable. 


Code  written  for  a  previous 

DOD  contract  that  was  re-  This  code  would  have  been  delivered  with  unlimited  rights;  however 

quired  as  a  deliverable  on  that  it  may  be  hard  to  find,  access,  and  reuse  it. 

contract 


Code  written  for  a  previous  By  default,  government  obtains  restricted  rights  to  this  data  if  it  is 
C  DOD  contract  that  was  not  identified  as  a  deliverable  under  the  current  contract;  the  govern- 
required  as  a  deliverable  ment  would  have  to  negotiate  for  GPR  rights  or  UL  rights. 


D 


Code  written  by  the  prime 
contractor  using  private  funds 


By  default,  government  obtains  restricted  rights  to  this  code  if  it  is 
identified  as  a  deliverable  under  the  current  contract;  the  govern¬ 
ment  would  have  to  negotiate  for  GPR  rights  or  UL  rights. 
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Table  2.  Software  components  and  their  associated  rights 


Source  of  component 


Associated  rights 


Fee  paid  to  subcontractor  will  depend  on  the  nature  of  the  delivera- 
Code  written  for  the  prime  ble  required  from  the  prime  by  the  government.  The  default  data 
contractor  by  a  subcontractor  rights  license  will  depend  on  the  "commercialness"  of  the  subcon¬ 
tractor's  contribution. 


F 


Code  licensed  by  the  prime 
contractor  from  a  commercial 
source 


By  default,  the  government  receives  the  standard  license  provided  to 
the  general  public.  The  commercial  vendor  may  be  willing  to  pro¬ 
vide  a  broader  license  in  exchange  for  a  higher  fee. 


In  general,  non-commercial  software  provided  to  the  DOD  will  have 
components  from  more  than  one  of  these  sources.  Thus  it  will  be 
important  for  DOD  acquisition  professionals  to  be  aware  of  the  fac¬ 
tors  that  determine  a  contractor’s  willingness  to  negotiate. 
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Appendix  C:  Data  rights  licensing  as  a 
bargaining  game 

The  act  of  requesting  a  price  for  data  rights  changes  the  structure  of 
negotiations  between  DOD  and  technology  firms  that  respond  to  a 
solicitation.  To  see  why,  consider  the  following  situation.  Suppose  that 
DOD  wishes  to  acquire  a  customized  product  in  each  of  two  periods 
and  expects  to  issue  a  separate  solicitation  for  each  period.  During 
the  first  period,  the  chosen  supplier  will  design  and  manufacture  the 
desired  product.  During  the  second  period,  either  the  period  1  pro¬ 
ducer  (the  incumbent)  or  a  new  firm  will  produce  the  next  genera¬ 
tion  product. 

The  product  design  created  in  period  1  can  be  treated  as  data;  DOD 
will  acquire  a  license  to  this  information  as  part  of  the  contracting 
process.  However,  the  specific  terms  of  the  government’s  license  to 
the  data  will  depend  on  a  variety  of  factors,  including 

•  the  source  (s)  of  funding  used  to  develop  design  components; 

•  the  extent  to  which  the  design  is  “commercial”  (in  the  sense 
defined  by  the  DEARS) ;  and 

•  the  details  of  negotiation  prior  to  contract  award. 

To  examine  the  sequence  of  events  in  this  scenario,  we  define  varia¬ 
bles  that  represent  values  of  interest  to  both  industry  and  DOD.  We 
adopt  the  following  notation  for  periods  1  and  2: 

Period  1 

•  B“  =  winning  bid  when  no  data  rights  package  is  requested 

•  d  =  documentation  and  preparation  cost  (if  any)  needed  to  en¬ 
sure  “transferability”  of  data  rights  to  one  or  more  third  party 
in  period  2 

•  p  =  price  of  a  license  for  the  additional  data  rights  that  do  not 
automatically  convey  to  the  government 


43 


Period  2 


•  C 2=  production  cost  for  the  incumbent  firm 

•  C 2  =  production  cost  for  any  new  supplier  without  access  to  the 
data  developed  in  period  1 

•  V gfe  =  the  cost  savings  realized  by  a  new  supplier  having  access 
to  all  period  1  data  as  government-furnished  equipment  (GFE) 

This  notation  makes  it  possible  to  characterize  the  sequence  of  events 
that  define  the  life  cycle  of  the  product  in  question — and  to  do  so  in 
a  general  way.  Several  important  assumptions  should  be  considered: 

•  Access  to  data  rights  has  the  potential  to  lower  period  2  pro¬ 
duction  costs  for  non-incumbent  firm(s)  by  the  amount  VGFE. 

•  Treating  data  with  data  rights  as  a  deliverable  (requiring  added 
documentation,  testing,  record-keeping,  etc.)  may  increase 
costs  for  the  period  1  supplier  by  an  amount  d. 

•  The  competitive  threat  (however  weak)  posed  by  new  suppliers 
defines  the  maximum  amount  that  the  incumbent  firm  can 
hope  to  receive  in  period  2. 

Figure  4  below  illustrates  the  decision  tree  implied  by  these  assump¬ 
tions.  This  decision  tree  illustrates  the  analytical  framework  needed 
to  tackle  the  question,  “What  is  the  most  that  DOD  would  be  willing 
to  pay  for  the  government  purpose  rights  to  the  data  developed  for 
the  first  period  contract?” 


Figure  4.  The  DOD  decision  tree 


Issue 

RFP 


DOD  defines 
CDRLs 


To  answer  the  question,  we  start  by  identifying  the  foreseeable  out¬ 
comes  for  period  2.  We  use  this  information  to  analyze  the  negotiat¬ 
ing  problem  that  DOD  faces  in  period  1. 

If  DOD  does  not  ask  for  data  rights  in  the  initial  contract,  then  the 
incumbent  firm  will  be  in  a  strong  bargaining  position  in  period  2, 
and  a  vendor  lock  environment  will  be  created.  Without  access  to  the 
incumbent’s  data,  a  competitor  would  have  to  develop  an  equivalent 
item,  component,  or  computer  software  from  scratch.  Thus,  the  new 
supplier’s  total  cost  in  period  2  would  be  significantly  higher  than  the 
incumbent’s  production  cost  at  that  time.  Since  the  incumbent  knows 
this,  we  assume  that  the  incumbent  submits  a  bid  equal  to  the  mini¬ 
mum  amount  that  would  allow  a  competitor  to  break  even  (i.e.,  the 
incumbent  bids  C*).  We  expect  DOD  to  accept  this  bid  since  there  is 
no  one  else  who  could  do  the  job  at  a  lower  price. 

The  scenario  is  rather  different  when  DOD  acquires  a  license  that  al¬ 
lows  it  to  transfer  the  design  to  one  or  more  competitors.  Such  a  li¬ 
cense  essentially  becomes  “government-furnished  equipment”  that 
would  allow  a  new  supplier  to  avoid  having  to  develop  an  alternative 
design.  Under  the  assumptions  above,  any  new  supplier  given  such  a 
license  would  save  V GFE  and  would  thus  be  able  to  compete  more  ef¬ 
fectively  with  the  incumbent.  In  this  situation,  we  assume  that  compe¬ 
tition  among  potential  suppliers  forces  them  to  bid  the  minimum 
amount  that  would  allow  a  new  supplier  to  break  even  (i.e.,  they 
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would  bid  C2  -  Vgfe)-  The  incumbent  anticipates  this  and  matches 
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the  bids  submitted  by  potential  entrants. 


We  next  consider  the  period  1  bargaining  problem.  In  the  absence  of 
a  request  for  data  rights  pricing,  we  suppose  that  competition  among 
period  1  bidders  yields  a  price  of  B“.  If  DOD  requests  data  rights 
pricing,  the  winning  bidder  will  face  a  cost  increase  of  d  (to  cover  the 
cost  of  data  preparation)  and  will  ask  for  an  amount  p  in  exchange 
for  the  data  rights.  Thus,  the  successful  period  1  bid  would  be 
m  +  d  +  v )  when  data  rights  pricing  is  requested. 

In  order  for  DOD  to  be  willing  to  pay  the  amount  requested  for  the 
data  rights,  the  life-cycle  cost  of  the  product  including  data  rights 
cannot  exceed  the  life-cycle  cost  of  the  product  alone.  More  formally, 

(Bl  +  d  +  p)  +  (C§  -  VGFE)  <  B\+  C\  (5) 

Simplifying  equation  (5)  yields 


p  <V  GFE  -  d  (6) 


In  other  words,  the  price  paid  by  DOD  for  additional  data  rights  must 
be  less  than  the  net  effect  that  this  information  has  on  the  cost  of  us¬ 
ing  a  new  supplier  in  period  2. 

The  result  suggests  a  method  of  developing  a  reality  check  for  data 
rights  valuations  submitted  by  industry.  In  the  above  model,  the  max¬ 
imum  price  that  DOD  is  willing  to  pay  is  defined  by  new  supplier’s 
potential  cost  savings  less  any  additional  data  preparation  expenses 
sustained  by  the  incumbent.  A  reasonable  proxy  for  new  supplier’s 
cost  savings  would  be  an  estimate  of  the  resources  required  for  such  a 
firm  to  develop  its  own  version  of  the  data  in  question. 


We  tacitly  assume  that  the  incumbent  is  at  least  as  efficient  in  production 
as  a  new  entrant  (i.e.,  that  C*  -  V GFE  ^  C £).  If  the  incumbent  is  less  effi¬ 
cient  than  one  or  more  of  the  potential  entrants,  then  the  final  price 
would  lie  between  Cf  and  C*  -  V GFE.  The  specific  price  would  depend 
on  the  extent  of  competition  among  the  potential  entrants. 


Appendix  D:  The  M4  carbine  controversy 

In  its  review  of  the  Army’s  decision  to  withdraw  a  2006  M4  solicita¬ 
tion,  the  DOD  Inspector  General  summarized  the  early  history  of  the 
dispute  between  the  Army  and  Colt  Defense  LLC  as  follows  ( [64] ,  pp. 
13-14): 


(U)  M4  Carbine  Technical  Data  Package.  In  June  1967,  Colt 
and  the  Government  entered  into  a  patent  license  agree¬ 
ment  for  the  M16  rifle.  In  March  1985,  Colt  and  the  Gov¬ 
ernment  extended  the  license  agreement  to  include  the  M4 
carbine  because  the  M4  carbine  was  a  derivative  of  the  Ml 6 
rifle.  The  license  agreement  gave  the  Government  limited 
rights  to  the  technical  data  and  placed  restrictions  on  its 
use.  The  license  agreement  included  a  provision  that  limits 
the  Army’s  right  to  transfer  or  release  the  technical  data 
package. 

(U)  Inappropriate  Release  of  the  M4  Carbine  Technical  Da¬ 
ta  Package.  DoD  Inspector  General  Report  No.  97-165, 
“Procurement  of  the  M4  Carbine,”  June  17,  1997,  stated 
that,  in  January  1996,  the  Army  released  the  M4A1  carbine 
technical  data  package  to  the  Navy.  The  Navy  requested  the 
technical  data  package  for  internal  use,  but  inappropriately 
released  it  in  August  1996  to  contractors  in  a  solicitation  for 
M4A1  adapter  kits.  Further,  the  report  stated  that  the  Army 
and  Navy  failed  to  protect  the  confidentiality  of  Colt’s  tech¬ 
nical  data  package  and  had  inadequate  controls  to  safe¬ 
guard  Colt’s  proprietary  data.  The  report  concluded  that 
the  M4A1  technical  data  package  was  inappropriately  re¬ 
leased  to  contractors  for  purposes  outside  the  scope  of  the 
M4  license  agreement. 

(U)  Lawsuit  Regarding  the  Inappropriate  Release  of  the  M4 
Carbine  Technical  Data  Package.  Colt  filed  a  lawsuit  against 
the  Government  regarding  the  rights  and  responsibilities  of 
each  party  under  License  Agreement  DAAF03-67-C-0108. 
On  December  24,  1997,  as  a  result  of  the  legal  settlement, 
the  Government  and  Colt  entered  into  an  addendum  to  the 
Technical  Data  Sales  and  Patent  License  for  the  M4  carbine 
which  clarified  the  safeguards  to  be  undertaken  by  the  Gov¬ 
ernment  with  respect  to  control  and  dissemination  of  li¬ 
censed  technology.  M4  carbine  licensed  technology 
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includes  proprietary  data,  improvements,  and  intellectual 
property.  Proprietary  data  includes  the  technical  data  pack¬ 
age. 

In  other  words,  Colt  agreed  to  drop  its  damage  claim  against  the  Ar¬ 
my  and,  in  exchange,  was  granted  sole  source  status  for  a  decade. 
When  in  1999  a  potential  supplier  challenged  the  legality  of  this 
agreement,  the  Court  of  Federal  Claims  found  that, 

this  agreement  recognizes  and  establishes  Colt's  claim  to 
proprietary  data  rights  in  the  M4  carbine  and  its  compo¬ 
nents....  Because  of  this  acknowledgment  of  Colt’s  proprie¬ 
tary  data  rights  in  the  M4,  the  Government  has  disabled 
itself  from  procuring  that  weapon  on  a  competitive  basis.  Of 
necessity,  Government  procurement  of  the  M4  may  now 
proceed  only  through  purchases  from  Colt’s.  [65] 

The  sole  source  clause  in  the  M4  Addendum  lasted  for  10  years; 
it  expired  in  July  2009.  As  table  3  shows,  the  unit  price  for  an  M4 
rose  significantly  from  1999  through  2006.  In  2006,  the  Army  is¬ 
sued  a  presolicitation  notice  indicating  its  intent  to  award  a  con¬ 
tract  for  an  alternative  to  the  M4.  Colt  responded  by  lowering  its 
price  and  offering  to  provide  attachments  that  had  been  previ¬ 
ously  provided  by  the  government. 
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FN  Manufacturing,  Inc.  v.  the  United  States  and  Colt’s  Manufacturing 
Company,  Inc.,  44  Fed.  Cl.  449  [65]. 


Table  3.  M4  unit  price  history 

Date 

Unit  price1 

Item 

purchased 

Contract/ 

Delivery  order 

Dec-99 

$521 

M4  carbine 

DAA20-98-C-0082-P0001 1 

Dec-02 

$912 

M4  carbine 

DAA20-02-C-01 1 5-P00004 

2005-2006 

$1,012 

M4  carbine 

W52  H09-04-D-0086-0040 

Presolicitation 

Feb-06 

' 

notice  for  M4 
replacement 

W52H09-06-R-01 95  (cancelled  6/2006) 

3/2006:  Colt 

$815  / 

M4-carbine/ 

Price 

concession 

$1,142 

M4-carbine 
with  BUIS  and 
ARSb 

W52  H09-04-D-0086-0040 

Dec-10 

$1,221 

"fully-equipped 

carbine" 

W52H09-07-D-0425-BR02- 

Apr-12 

$673  c 

R4  (Remington) 

W56HZV-1 2-D-0056c 

a.  Unless  otherwise 

indicated,  price 

data  are  taken  from 

[66], 

b.  BUIS  refers  to  "Back  Up  Iron  Sight";  ARS  refers  to  "Adaptor  Rail  System." 

c.  Price  and  contract  information  are  taken  from  [67], 
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Appendix  E:  KSD,  Inc.  v.  U.S.  and  McDonnell 
Douglas  Helicopter  Company  (MDHC) 

This  case  illustrates  the  importance  of  considering  the  long-term  ef¬ 
fects  of  not  securing  data  rights  for  key  products  that  require  multi¬ 
ple  purchases  or  long-term  contracts.  The  opinion  issued  by  the 
United  States  Court  of  Federal  Claims  describes  the  facts  of  the  case 
as  follows: 

This  case  arises  out  of  a  solicitation  for  main  rotor  strap  as¬ 
semblies  for  the  AH-64  Apache  Helicopter.  The  main  rotor 
strap  assembly  retains  the  main  rotor  blade  to  the  rotor  hub 
of  the  helicopter.  In  2001,  the  Army  awarded  a  sole  source 
contract  to  MDHC  for  an  “improved”  main  rotor  strap  as¬ 
sembly,  which  is  commonly  referred  to  by  contractors  and 
the  government  as  a  “Fat  Boy”  strap  pack.  Before  the  Army 
began  acquiring  the  “Fat  Boy”  strap  packs  from  MDHC,  the 
plaintiff,  KSD,  had  provided  the  Army  with  an  earlier  ver¬ 
sion  of  the  strap  pack,  known  as  the  “Jenny  Craig”  strap 
pack.  The  2001  sole  source  contract  to  MDHC  for  “Fat  Boy” 
strap  packs  expired  on  December  31,  2005.  A  new  solicita¬ 
tion  was  issued,  a  contract  awarded,  and  KSD  protests  the 
sole  source  award  of  the  2005  “Fat  Boy”  contract  to  MDHC. 

On  May  17,  2005,  the  United  States  Army  Aviation  and  Mis¬ 
sile  Command  (AMCOM)  published  a  pre-solicitation  no¬ 
tice  for  solicitation  No.  W58RGZ-04-R-0982  on  the  Federal 
Business  Opportunities  (FedBizOpps)  website,  Error!  Hy¬ 
perlink  reference  not  valid..  The  May  17,  2005  notice  an¬ 
nounced  a  requirement  for  135  parts  in  support  of  the 
Army’s  AH-64  Apache  Helicopter.  One  of  the  parts  listed  in 
the  notice  was  the  Main  Rotor  Strap  Assembly,  part  no.  7- 
511411146-3,  which  is  the  “Fat  Boy”  strap  pack  assembly. 

The  Army  had  designated  the  “Fat  Boy”  strap  pack  assembly 
a  critical  safety  item  “whose  failure,  malfunction,  or  absence 
could  cause  loss  of  or  serious  damage  to  the  aircraft  and/ or 
serious  injury  or  death  to  the  occupants.”  For  this  reason, 
the  part  could  be  procured  only  from  an  “approved  source” 
that  has  satisfied  the  Army’s  engineering  and  testing  re¬ 
quirements.  The  May  17,  2005  notice  stated  that  the  Army 
intended  to  award  McDonnell  Douglas  Helicopter  Compa¬ 
ny  (MDHC)  a  three-year,  indefinite  delivery,  indefinite 
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quantity  (IDIQ)  contract  for  the  135  different  parts,  includ¬ 
ing  the  “Fat  Boy”  strap  pack  assembly,  on  a  sole  source  basis. 
KSD,  Inc.  (KSD)  protested  the  2005  sole  source  award  of 
the  “Fat  Boy”  contract  to  MDHC. 

In  1996,  before  KSD  had  submitted  its  unsolicited  proposal 
to  modify  the  “Jenny  Craig”  strap  pack,  Boeing  had  submit¬ 
ted  its  own  unsolicited  proposal  to  design  an  improved  strap 
pack  for  the  United  States  Army  Aviation  and  Missile  Com¬ 
mand  (AMCOM).  AMCOM  conducted  an  economic  evalua¬ 
tion  of  Boeing’s  proposal  and  verbally  advised  Boeing  that 
government  funding  was  not  available  for  the  design  of  the 
new  strap  pack.  Boeing,  however,  was  advised  that  it  could 
pursue  an  improved  strap  pack  under  the  Department  of 
Defense’s  “commercialization  initiative,”  pursuant  to  which 
“industry  designs,  develops  and  qualifies  a  new  product  at 
their  own  expense,  and  then  markets  it  to  their  customers.” 
In  September,  1999,  while  Boeing’s  qualification  procedure 
of  the  “Fat  Boy”  was  underway,  KSD  requested  an  oppor¬ 
tunity  to  compete  as  a  prime  vendor  for  the  “Fat  Boy”  strap 
pack  and  requested  all  engineering  data  required  to  sup¬ 
port  the  redesign  and  testing  of  the  current  strap  pack  as¬ 
sembly.  AMCOM  responded  to  KSD’s  request  on  October  5, 
1999,  informing  KSD  that  because  the  government  did  not 
pay  Boeing  for  the  redesign  of  the  strap  packs,  the  data  is 
considered  proprietary  to  Boeing  and,  therefore,  cannot  be 
provided  for  KSD’s  use.  In  the  same  letter,  the  Army  offered 
to  assist  KSD  in  redesigning  and  qualifying  a  new  strap  pack. 
Specifically,  the  Army  stated  that  “if  KSD  is  interested  in  re¬ 
designing  and  qualifying  a  strap  pack,  the  Government  will 
afford  the  same  assistance  given  to  Boeing  during  its  rede¬ 
sign  and  qualification.  There  is  no  evidence  in  the  record 
that  KSD  responded  to  this  offer  for  assistance. 

On  July  18,  1999,  the  government  issued  a  Justification  and 
Approval  (J&A)  for  a  sole  source  contract  of  the  improved 
“Fat  Boy”  strap  packs  to  MDHC.  In  the  J&A,  the  Army  stated 
that  “MDHC  is  the  only  responsible  source  capable  of 
providing  the  supplies  or  services  necessary  for  manufacture 
of  Apache  Longbow  aircraft.”  In  a  letter  sent  to  AMCOM  on 
September  10,  1999,  KSD  expressed  its  concern  over  the 
sole-source  contract  to  Boeing,  informing  AMCOM  of  KSD’s 
history  with  the  manufacture  and  production  of  helicopter 
strap  packs,  including  more  than  4,000  strap  packs  that  were 
ordered  by  the  Army  from  KSD  for  the  AH-64  helicopter.  In 
the  letter,  KSD  also  requested  that  it  be  provided  the  same 
opportunity  to  compete  on  the  1999  contract  as  the  prime 
vendor.  In  response  to  KSD’s  September  10,  1999  letter,  and 


to  KSD's  concerns  about  the  sole  source  contract  to  MDHC, 
the  Army  stated  that  Boeing  had  performed  all  of  the  re¬ 
search  and  development  on  the  new  strap  pack  with  no 
government  funding.  Therefore,  AMCOM  contended: 
“Since  the  Government  did  not  pay  for  the  Boeing  redesign 
of  the  strap  pack,  the  data  is  considered  proprietary  to  the 
Boeing  Company  and  therefore  cannot  be  provided  for 
KSD’s  use.” 

On  August  1,  2000,  the  Army  approved  Boeing’s  qualifica¬ 
tion  for  its  design  of  the  “Fat  Boy”  strap  pack.  On  Novem¬ 
ber  29,  2000,  AMCOM  Contracting  Officer  Robert  Deppe  2 
executed  another  J&A  for  other  than  full  and  open  compe¬ 
tition  with  respect  to  the  procurement  of  “Fat  Boy”  strap 
packs.  The  November,  2000  J&A  concluded  that:  “The 
Apache  Attack  Helicopter  Project  Manager’s  Office  has 
found  no  other  contractor  that  possesses  the  detailed  tech¬ 
nical  information  required  to  manufacture  the  strap  packs. 
No  viable  competitive  alternative  exists  for  this  requirement 
as  MDHC  is  the  only  source  possessing  the  required  tech¬ 
nical  data  and  corporate  knowledge.”  The  following  day, 
AMCOM  published  a  pre-solicitation  notice  in  the  Com¬ 
merce  Business  Daily  (CBD)  providing  notice  of  the  pro¬ 
curement  of  2100  “Fat  Boy”  strap  pack  assemblies  upon  a 
sole  source  basis,  with  an  option  to  purchase  additional 
strap  packs  as  spares.  The  notice  also  stated  that  a  sole 
source  award  was  justified  because  “the  strap  pack  is  a 
commercial  product  developed  by  MDHC  and  the  technical 
data  is  proprietary  to  the  manufacturer.”  KSD  filed  an  agen¬ 
cy  level  protest  on  December  7,  2000,  asserting  that  the  “Fat 
Boy”  strap  pack  was  not  a  commercial  item  or  product  as 
justified  by  the  Army  in  its  November,  2000  J&A.  By  letter 
dated  February  14,  2001,  the  Army  denied  KSD’s  protest. 
The  Army  stated  in  its  denial  of  KSD’s  agency  protest  that: 
“The  use  of  the  term  ‘commercial’  as  stated  in  the  [Com¬ 
merce  Business  Daily]  synopsis  has  been  misconstrued  and 
is  not  used  in  context  of  the  definition  for  a  commercial 
item  in  FAR  Part  2.0.”  The  letter  continued  that  the  “Fat 
Boy”  had  been  “solely  developed  by  MDHC  under  a  con¬ 
tractor  funded  commercialization  program.” 

On  March  19,  2001,  the  AMCOM  Small  Business  Admin¬ 
istration  (SBA)  Competition  Advocate,  Wade  Griffin,  Jr., 
approved  the  November,  2000  J&A,  but  recommended  ac¬ 
quisition  of  “the  basic  quantity  only”  (emphasis  in  original) . 
In  addition,  Mr.  Griffin  requested  information  concerning 
“potential  sources  seeking  qualification  prior  to  any  option 
exercise.”  On  April  3,  2001,  three  weeks  later,  Ralph  Massey, 
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an  SBA  Procurement  Center  Representative,  sent  a  memo¬ 
randum  to  Mr.  Griffin  which  stated  that  the  “Fat  Boy”  con¬ 
tract  would  result  in  the  Army  “for  all  practical  purposes,  be 
using  this  sole  source  buy  to  repay  Boeing/McDonnell 
[somewhere  between  $15M  and  $20M]  for  their  Non- 
Recurring  Engineering  costs  for  both  the  development  and 
qualification  testing  of  the  new  strap  assembly.”  A  subse¬ 
quent  memorandum  from  Mr.  Massey  in  the  record,  dated 
April  27,  2001,  stated  that,  “This  procurement  is  a  perfect 
example  of  the  fallacy  of  depending  upon  the  ‘DOD  Com¬ 
mercialization  Initiative'  program  to  fund  needed  redesigns 
of  items  on  a  weapons  platform,  rather  than  having  a  PM 
include  an  adequate  funding  fine  in  the  POM.”  The  same 
memorandum  indicated  that  the  initial  procurement  may 
have  been  caused  by  the  Army’s  failure  to  plan  funding  for 
the  redesign  of  the  strap  pack.  Specifically,  Mr.  Massey  stat¬ 
ed:  “The  current  undesirable  sole  source  acquisition  situa¬ 
tion  can  be  traced  directly  to  the  decision  in  the  mid-1990s 
by  the  ‘Strap  Team’  at  St.  Louis  which  did  not  adequately 
push  the  case  for  NRE  [Non-Recurring  Engineering]  funds 
to  support  competition  on  re-design  of  an  improved  MR 
strap  assembly.” 

On  July  31,  2001,  the  Army  awarded  MDHC  a  sole-source 
contract,  No.  DAAH23-01-C-0092,  to  supply  1,992  “Fat  Boy” 
strap  packs  to  AMCOM,  with  a  government  option  to  pur¬ 
chase  an  additional  220  strap  packs.  Also,  on  the  same  date, 
the  Army  modified  a  different  existing  contract,  No. 
DAAH23-00-C-0001 ,  for  MDHC  to  provide  240  “Fat  Boy” 
strap  packs.  Under  each  contract,  the  unit  price  of  the  “Fat 
Boy”  strap  pack  was  [deleted]. 

In  the  2001  contract  and  in  a  separate  modification  of  an 
existing  contract,  the  government  and  MDHC  specifically 
agreed  that  the  technical  data  rights  pertaining  to  the  “Fat 
Boy”  strap  pack  would  not  be  provided  to  the  government. 
Specifically,  the  2001  contract  incorporated  the  clause  at 
Defense  Federal  Acquisition  Regulations  Supplement 
(DFARS)  252.227-7015  (NOV  1995),  “Technical  Data  - 
Commercial  Item,”  and  stated  that  the  section  “[a]pplies  to 
Improved  Strap  Pack,  P/N  7-511411146-1.  Technical  Data 
pertaining  to  Improved  Strap  Pack  is  not  delivered  under 
this  contract.  The  Government’s  rights  are  limited  to  the 
rights  defined  in  this  clause.”  Similarly,  the  contract  modifi¬ 
cation  for  contract  No.  DAAH23-00-C-0001  stated:  “Both 
parties  agree  that  DFARS  [2]  52 [.] 227-7015  is  incorporated 
by  reference  in  Section  I  and  applies  to  the  design  and  de¬ 
velopment  technical  data  of  the  Improved  Strap  Pack,  P/N 


7-511411146-1  only.  The  only  data  to  be  delivered  under  this 
effort  is  specified  in  Section  C,  Statement  of  Work,  Attach¬ 
ment  01.” 

On  May  17,  2005,  AMCOM  posted  its  pre-solicitation  no¬ 
tice  on  the  FedBizOpps  website  advertising  that  it  was  go¬ 
ing  to  sole-source  the  “Fat  Boy”  strap  pack  contract  to 
MDHC.  The  notice  stated  that  AMCOM  intended  “to  es¬ 
tablish  a  three  (3)  year  Indefinite  Delivery  Indefinite 
Quantity  (IDIQ)  type  contract  with  two  unpriced  options 
to  extend  the  period  of  performance  for  an  additional 
three  years  (each  option)  applicable  to  AH-64  Apache  Hel¬ 
icopter  Spares.”  KSD  submitted  an  agency  level  protest  to 
AMCOM  on  August  15,  2005.  KSD  based  its  agency  protest 
on  two  claims.  First,  KSD  argued  that  the  “Fat  Boy”  strap 
pack  was  a  modification  of  an  existing  part,  which  was 
owned  by  the  government,  and  that  the  modification  was 
based  on  a  “Commercialization  Initiative,”  but  that  the 
new  part  does  not  meet  the  definition  of  a  “Commercial 
Item”  under  FAR  2.101  (2005).  Second,  KSD  argued  that 
the  solicitation  for  the  “Fat  Boy”  strap  pack  did  not  “con¬ 
form  with  the  spirit,  intent,  or  requirements  of  the  Com¬ 
petition  in  Contracting  Act  of  1984.”  KSD  stated  that  the 
Army’s  action  “has  resulted  in  all  competition  being  elimi¬ 
nated  for  this  item  in  the  future.”  Among  the  relief  re¬ 
quested,  KSD  asked  in  its  agency  protest  that  the  Army 
provide  KSD  with  technical  data  so  that  it  could  submit  a 
Source  Approval  Package. 

The  Army  responded  to  and  denied  KSD's  agency  protest 
on  September  15,  2005.  In  its  response,  the  Army  stated  that 
because  Boeing  developed  the  “Fat  Boy”  at  private  expense, 
“the  technical  data  package  is  proprietary  data  not  owned 
by  the  Government,  and  therefore  unavailable  for  distribu¬ 
tion  by  the  Army.”  The  Army  further  stated  that:  “The  Main 
Rotor  Strap  Assembly  is  not  a  commercial  item  as  defined 
by  the  Federal  Acquisition  Regulations.  (FAR)  Subpart 
2.101."  In  another  AMCOM  internal  memorandum,  the 
Army  indicated  that  “the  strap  pack  does  not  qualify  as  a 
commercial  item  under  the  Federal  Acquisition  Regulation 
(FAR)  2.101(b),  definition  of  a  commercial  item.  The  AH- 
64  Attack  Helicopter  is  dedicated  to  a  military  function  with 
no  civilian  counterpart.”  Similarly,  in  the  July  25,  2005  J&A, 
for  the  “Fat  Boy”  strap  pack,  the  Army  further  stated  that 
“none  of  these  items  are  identified  as  commercial  items.” 

KSD  initially  protested  to  the  General  Accounting  Office 
(GAO),  which  dismissed  KSD's  protest  on  October  31,  2005. 
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The  GAO  found  that  KSD  was  “not  an  interested  party  with¬ 
in  the  meaning  of  [GAO’s]  Bid  Protest  Regulations,  4  C.F.R. 

§  21.0(a)  (2005).”  In  its  opinion,  the  GAO  stated:  “We  have 
consistently  held  that,  where  an  agency  issues  a  presolicita¬ 
tion  notice  advising  that  it  intends  to  conduct  a  sole-source 
acquisition,  a  prospective  offeror  is  required,  as  a  perquisite 
[sic]  to  filing  a  protest  in  our  Office,  to  have  submitted  a 
timely  expression  of  interest  in  response  to  the  Fed- 
BizOp[p]s  notice.  ...  It  follows  that  where,  as  here,  a  firm 
does  not  submit  a  timely  expression  of  interest  in  response 
to  the  presolicitation  notice,  it  is  ineligible  to  compete  for 
the  requirement.”  Thus,  the  GAO  dismissed  KSD's  protest 
because  it  found  that  it  did  not  respond  to  AMCOM’s  pre¬ 
solicitation  notice  posted  on  the  FedBizOpps  website  on 
May  17,  2005.  KSD  filed  its  bid  protest  complaint  and  mo¬ 
tions  for  preliminary  and  permanent  injunction  in  this 
court  on  November  22,  2005. 

KSD,  Inc.  argued  that  the  government’s  actions  violated 
Competition  in  Contracting  Act  (CICA)  by  failing  to 
properly  compete  the  contract  for  “Fat  Boy”  strap  packs. 

[21] 

Ultimately,  the  court  found  that  the  Army  had  acted  reasonably  in 
announcing  a  sole  source  award  for  the  “Fat  Boy”  contract.  Specifical¬ 
ly,  the  court  found  that  since  the  Army  had  not  licensed  data  rights 
from  MDHC,  it  did  not  “improperly  withhold”  them  from  KSD.  Fur¬ 
thermore,  the  court  found  that  the  Army  had  provided  a  proper  justi¬ 
fication  for  a  sole  source  procurement  (based  on  its  lack  of  technical 
data  rights  pertaining  to  the  “Fat  Boy”  strap  pack) : 

In  the  2001  contract,  the  government  specifically  negotiated 
away  its  rights  to  any  technical  rights  for  the  “Fat  Boy”  strap 
pack.  Therefore,  when  the  government  solicited  the  2005 
contract,  it  properly  indicated  that  it  did  not  have  technical 
data  rights  and  that  Boeing  was  the  only  approved  source  of 
the  “Fat  Boy”  strap  pack.  Moreover,  KSD,  Inc.  was  not  an 
approved  source  to  supply  the  product.  Because  the  plaintiff 
has  not  proven  that  the  government’s  actions  were  arbitrary, 
capricious,  or  otherwise  not  in  accordance  with  the  law,  or 
that  the  plaintiff  was  prejudiced,  the  court  denied  the  plain¬ 
tiffs  motion  for  preliminary  and  permanent  injunctive  re¬ 
lief.  [21] 


Appendix  F:  Software  cost  estimation  methods 

The  function  point  method 

The  Function  Point  method  was  pioneered  at  IBM  in  the  mid-1970s. 
Allan  Albrecht,  an  IBM  software  engineer,  first  published  a  descrip¬ 
tion  of  this  approach  in  1979  [29];  Albrecht  and  Gaffney  published 
the  first  major  refinement  in  1983  [30].  Since  1986,  the  International 
Function  Point  User  Group  (IFPUG)  has  maintained  a  Function  Point 
Counting  Practices  Manual.  The  current  version  can  be  downloaded 
from  http:/ /www.ifpug.org/. 

Anthony  DeMarco,  president  and  managing  member  of  Price  Sys¬ 
tems  LLC.,  defines  Albrecht’s  approach  as  follows: 

Function  point  sizing  involves  counting  five  different  cate¬ 
gories  of  functions  in  a  software  application:  inputs,  outputs, 
inquiries,  interfaces,  and  internal  files.  These  are  functions 
the  user  of  the  application  can  see  and  identify.  Each  func¬ 
tion  is  qualified  in  terms  of  complexity  (Low,  Average,  or 
High)  and  then  multiplied  by  a  corresponding  complexity 
weight  to  achieve  a  function  point  count,  a  measure  of  the 
size  of  the  function.  The  sum  of  function  point  counts  for 
the  functions  is  called  the  total  unadjusted  function  point 
count  (UFPC).  Next,  fourteen  general  system  characteristics 
are  rated  with  respect  to  degree  of  influence,  zero  through 
five  with  zero  indicating  no  influence  and  five  indicating  an 
extremely  strong  influence.  The  characteristics  include 
qualities  such  as  data  communications,  performance,  and 
operational  ease.  The  sum  of  the  degrees  of  influence  for 
the  fourteen  characteristics  is  used  to  make  a  value  adjust¬ 
ment  to  the  UFPC.  The  result  is  the  total  function  point 
count  for  the  application.  [31] 

Feature  point  method 

The  Feature  Point  method  was  developed  in  1986  at  Software 
Productivity  Research  (www.spr.com)  under  the  auspices  of  Capers 
Jones.  Chapter  13  of  the  Air  Force  Guidelines  defines  feature  points  as 
follows: 
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A  derivative  of  function  points,  feature  points  were  devel¬ 
oped  to  estimate/measure  real-time  systems  software  with 
high  algorithmic  complexity  and  generally  fewer  in¬ 
puts/outputs  than  MISs....In  addition  to  the  five  standard 
function  point  parameters,  feature  points  include  an  algo¬ 
rithm  (s)  parameter  which  is  assigned  the  default  weight  of 
3.  The  feature  point  method  reduces  the  empirical  weights 
for  logical  data  files  from  a  value  of  10  to  7  to  account  for 
the  reduced  significance  of  logical  files  in  real-time  systems. 

([25],  p.  13-9) 

Jones  [32]  provides  further  details  on  the  differences  between  the 
function  point  and  feature  point  methods. 

Predictive  object  points  (POPS) 

The  POPs  metric  was  developed  by  Arlene  Minkiewicz  at  PRICE  Sys¬ 
tems  LLC  and  first  published  in  1997.  Minkiewicz  describes  the  ap¬ 
proach  as  follows: 

The  POPs  metric  combines  several  measures  popular  in  the  literature 
to  establish  a  metric  suitable  for  predicting  effort  and  tracking 
productivity.  The  metric  at  the  heart  of  the  POPs  calculation  is 
Weighted  Methods  per  Class  (WMC).  This  metric  examines  each  top- 
level  class  (or  each  distinct  object  from  the  user’s  perspective)  and  as¬ 
signs  a  weight  to  the  behaviors  (methods)  of  that  class.  Once  a  value 
for  WMC  has  been  calculated,  the  POPs  counter  combines  this  with 
information  about  the  groupings  of  objects  into  classes  and  the  rela¬ 
tionships  between  these  classes  of  objects  to  assign  the  POPs  count. 
[33] 
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Glossary 


AMCOM 

ARS 

AWACS 

BUIS 

C4I 

CDRL 

CICA 

COCOMO 

COTS 

cs 

CSD 

DAU 

DFARS 

DID 

DOD 

FedBizOpps 

FPA 

GFE 

ICP 

IDCC 

IDIQ 


Army  Aviation  and  Missile  Command 
Adaptor  rail  system 

Airborne  Warning  and  Control  System 
Back  up  iron  sight 

Command,  Control,  Communications,  Computers,  &  In¬ 
telligence 

Contract  Data  Requirements  List 
Competition  in  Contracting  Act 
Constructive  COst  MOdel 
Commercial-off-the-shelf 
Computer  software 
Computer  software  documentation 
Defense  Acquisition  University 

Defense  Federal  Acquisition  Regulation  Supplement 

Data  Item  Description 

Department  of  Defense 

Federal  Business  Opportunities  web  site 

Government-furnished  equipment 

Government-furnished  equipment 

Item,  component,  process 

Integrated  Dual-use  Commercial  Companies 

Indefinite  delivery,  indefinite  quantity 
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IFPUG 

International  Function  Point  User  Group 

MDHC 

McDonnell-Douglas  Helicopter  Company 

MIS 

Management  information  system 

NDI 

Non-developmental  item 

OSS 

Open  source  software 

PNVG 

Panoramic  night  vision  goggle 

PRICE-H 

PRICE  hardware  model 

PRICE-L 

PRICE  lifecycle  model 

PRICE-S 

PRICE  software  model 

RFP 

Request  for  proposal 

RUL 

Remaining  useful  life 

SBIR 

Small  Business  Innovative  Research 

SLIM 

Software  Lifecycle  Management 

SLOC 

Software  lines  of  code 

TD 

Technical  data 

UFPC 

Unadjusted  function  point  count 

WBS 

Work  break-down  structure 

WMC 

Weighted  Methods  per  Class 
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